views:

206

answers:

1

Would it make sense to perform git rebase while preserving the commit timestamps?

I believe a consequence would be that the new branch will not necessarily have commit dates chronologically. Is that theoretically possible at all? (e.g. using plumbing commands; just curious here)

If it is theoretically possible, then is it possible in practice with rebase, not to change the timestamps?

For example, assume I have the following tree:

master <jun 2010>
  |
  :
  :
  :     oldbranch <feb 1984>
  :     /
oldcommit <jan 1984>

Now, if I rebase oldbranch on master, the date of the commit changes from feb 1984 to jun 2010. Is it possible to change that behaviour so that the commit timestamp is not changed? In the end I would thus obtain:

      oldbranch <feb 1984>
      /
 master <jun 2010>
    |
    :

Would that make sense at all? Is it even allowed in git to have a history where an old commit has a more recent commit as a parent?

Edit

A crucial question of Von C helped me understand what is going on: when your rebase, the committer's timestamp changes, but not the author's timestamp, which suddenly all makes sense. So my question was actually not precise enough. The answer is that rebase actually doesn't change the author's timestamps (you don't need to do anything for that), which suits me perfectly.

+2  A: 

You could try, for a non-interactive rebase

git rebase --ignore-date

(from this SO answer)

This is passed to git am, which mentions:

 --ignore-date

By default the command records the date from the e-mail message as the commit author date, and uses the time of commit creation as the committer date.
This allows the user to lie about the author date by using the same value as the committer date.

For git rebase, this option is "Incompatible with the --interactive option."

Since you can change at will the timestamp of old commit date (with git filter-branch), I suppose you can organize your Git history with whatever commit date order you want/need, even set it to the future!.


As Olivier mentions in his question, the author date is never changed by a rebase;
From the Pro Git Book:

  • The author is the person who originally wrote the work,
  • whereas the committer is the person who last applied the work.

So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit.

To be extra clear, in this instance, as Olivier comments:

the --ignore-date does the opposite of what I was trying to achieve!
Namely, it erases the author's timestamp and replace them with the commits timestamps!
So the right answer to my question is:
Do not do anything, since git rebase does actually not change authors' timestamps by default.

VonC
Interesting about the arbitrary dates to commit. However, `git rebase --ignore-date` does not work. It changes the dates of the rebased commits.
Olivier
@Olivier: strange: did you made a *non*-interactive rebase? And between the Author Date and the Committer Date, are we sure to monitor the "right" date?
VonC
Thanks VonC, the difference between author and committer timestamp, that's what makes it all suddenly clear. I wrote the answer to my question in my post, but feel free to adapt your answer to reflect that.
Olivier
@Olivier: good point. I have completed my answer to reflect the difference between the two dates.
VonC
@VonC: to be more precise: the `--ignore-date` does the *opposite* of what I was trying to achieve! Namely, it erases the author's timestamp and replace them with the commits timestamps! So the right answer to my question is: do not do anything, since `git rebase` does actually not change authors' timestamps by default.
Olivier