--- Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
