Re: Everyone, please stop making my life more difficult

[Sam Steingold <sds@gnu.org>]

> * David Kastrup <qnx@tah.bet> [2014-09-12 16:36:59 +0200]:
>
> 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.

I thought that rebase _moves_ commits, not _creates_ them anew.
Just like "mv" does not change ctime of a file,
rebase must not change the commit time.


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1265
http://www.childpsy.net/ http://think-israel.org http://openvotingconsortium.org
http://mideasttruth.com http://memri.org http://ffii.org
Lisp: Serious empowerment.