Re: merge time

[david@lang.hm]

On Sun, 29 Jul 2007, Matthew L Foster wrote:

> --- Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> You misunderstand. It would do so both for the newly merged commits *and*
>> for the old commits. Because _you_ think the "new" commits got merged, but
>> it's logically exactly equivalent to saying that the *old* commits got
>> merged.
>>
>> So now *every* single commit would get the timestamp of the merge.
>>
>> See? It would be pointless.
>
> Ok maybe I am still confused. If a repository is in state A and a merge happens changing it to
> state B we can give the changes that got us to B the timestamp of the merge? Since the changes
> that got us from A to B were all merged locally at the same time they should be given the same
> timestamp, right? Please explain more about how changes/commits in state A would also be given the
> timestamp of the merge?
>
> When I say local time I also really mean local commit order as both should be interchangeable
> unless you widly misset/change your local clock. Git/gitweb could have an option to sort/display
> based on local commit order and maybe have check for if local time order is out of sync with local
> commit order.

one feature of git (and I think of truely distributed change management 
systems)

say you have tree A and I have tree B

if you clone your tree and merge from mine, and I clone my tree and merge 
from yours, the result of both merges _must_ be the same there will be 
trouble when we both try and merge with tree C later on.

another thing is that a given commit cannot be changed once it's created 
(if it was changed it wouldn't have the same sha1 value) so you can't just 
go around changeing dates on commits that took place elsewhere.

David Lang