Re: merge time
From: <hidden>
Date: 2016-06-15 22:43:24
On Sun, 29 Jul 2007, Matthew L Foster wrote:
quoted hunk ↗ jump to hunk
--- Linus Torvalds <torvalds@linux-foundation.org> wrote:quoted
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