Re: merge time
- From
- Matthew L Foster <mfoster167@yahoo.com>
- Date
- Jul 30, 2007, 04:10 UTC
- Message-ID
- <994493.95349.qm@web51001.mail.re2.yahoo.com>
- In-Reply-To
- <alpine.LFD.0.999.0707292007440.4161@woody.linux-foundation.org>
--- Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 8 quoted lines
> 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