Re: Everyone, please stop making my life more difficult

[David Kastrup <dak@gnu.org>]

Sam Steingold <sds@gnu.org> writes:

>> * Andreas Schwab <fpujno@yvahk-z68x.bet> [2014-09-12 13:47:44 +0200]:
>>
>> "Eric S. Raymond" <esr@thyrsus.com> writes:
>>
>>> This choice helps avoid collisions.  It is unlikely that one
>>> committer will ever manage two commits in the same clock second.
>>
>> That's pretty easy if you are rebasing.
>
> Are you saying that rebasing changes the timestamp?!

The commit timestamp?  Most certainly.

> I.e., I make a commit X today and tomorrow rebase (= remove X; pull from
> upstream; reapply X) it.
> Is X now dated today or tomorrow?
> If the answer is "tomorrow", this looks like a bug.

If the commit timestamp were anything but "tomorrow" it would be a bug.
The whole point of a commit timestamp is to track who created a commit
when.  Since a rebase creates commits, obviously the commit timestamp
will correspond to the time of the rebase, and the commit author will
correspond to the person doing the rebase.

Which is exactly why using "commit author/timestamp" is not going to cut
it as a unique identifier when rebases come into play.

-- 
David Kastrup