Re: merge time

--- 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.

-Matt


       
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222