"Rebase and merge" should keep the original commits' timestamps

[andreynering]

Select Topic Area

Product Feedback

Body

When merging a PR by "rebase and merge", the commit date and time of every commit in the PR are overridden to the PR merge time.

This was always unexpected to me, as this is not how the actual git rebase command works. In my opinion, every commit should preserve its original commit date and time.

This has no relation to the actual order of the commits. By the way Git works, the commits should still all be moved to the top of the branch, but with no changed to its timestamp.

---

An additional thought is that maybe even "squash and merge" should keep the last commit date and time as the squashed commit timestamp. A PR often has even a single commit, so why not preserve its original timestamp? I think the current behavior is specially unexpected to "rebase and merge", though.

[alixodendhal]

I ran into this same issue. I cannot understand why they made this customization to do what we don't want.

It's noted here in their docs.

The rebase and merge behavior on GitHub deviates slightly from git rebase. Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit.

---

I have a use case where I have staging and main branches. I want staging to ff or rebase it's history onto main keeping their history identical for obvious reasons.

This is what I have to deal with:

I had to write a custom github action to forcibly rebase backwards so that staging gets this nonsense re-written history.

You can see that I have a commit hash then it gets re-written on Githubs rebase merge and I have to update staging. I shouldn't have to update staging. It had the commit before.

[anton-at-baraka]

It does not seem GH is going to fix that. Could you share the GH action you implemented?

[alixodendhal]

https://gist.github.com/alixodendhal/b630d9ff7ef7eaa7ed06e7b9fc51d7cc

You need to set an access token secret in the Repo. Since you are forcibly re-writing staging you will need to force push. Which is less than ideal. I allowed only this specific access token to re-write the commit history.

[ironchicken]

git even supports this behaviour: you can git rebase with the flag --committer-date-is-author-date. It feels like it should be quite trivial for the Github "rebase and merge" implementation to apply that flag.