On Sun, 29 Jul 2007, Matthew L Foster wrote:
--- 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.
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
-
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
