{"thread":{"id":"9302","subject":"Re: merge time","startedAt":"2007-07-30T02:28:24Z","lastAt":"2007-07-30T22:11:09Z","messageCount":9,"participants":["Matthew L Foster","Linus Torvalds","david@lang.hm","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"49042","messageId":"686661.84825.qm@web51011.mail.re2.yahoo.com","threadId":"9302","inReplyTo":null,"subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T02:28:24Z","receivedAt":"2007-07-30T02:28:24Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\n> but if git did what you wanted it would show every commit with the time of \n> the merge, and that wouldn't help you anyway.\n \nActually that is exactly what I want. I want to know what local time change X and Y (and all\nchanges) were merged locally.\n\n-Matt\n\n\n\n       \n____________________________________________________________________________________\nBuilding a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.\nhttp://smallbusiness.yahoo.com/webhosting \n"},{"id":"49045","messageId":"alpine.LFD.0.999.0707292007440.4161@woody.linux-foundation.org","threadId":"9302","inReplyTo":"686661.84825.qm@web51011.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-30T03:09:01Z","receivedAt":"2007-07-30T03:09:01Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 29 Jul 2007, Matthew L Foster wrote:\n> \n> > but if git did what you wanted it would show every commit with the time of \n> > the merge, and that wouldn't help you anyway.\n>  \n> Actually that is exactly what I want. I want to know what local time change X and Y (and all\n> changes) were merged locally.\n\nYou misunderstand. It would do so both for the newly merged commits *and* \nfor the old commits. Because _you_ think the \"new\" commits got merged, but \nit's logically exactly equivalent to saying that the *old* commits got \nmerged.\n\nSo now *every* single commit would get the timestamp of the merge.\n\nSee? It would be pointless.\n\n\t\t\tLinus\n"},{"id":"49053","messageId":"994493.95349.qm@web51001.mail.re2.yahoo.com","threadId":"9302","inReplyTo":"alpine.LFD.0.999.0707292007440.4161@woody.linux-foundation.org","subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T04:10:25Z","receivedAt":"2007-07-30T04:10:25Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Linus Torvalds <torvalds@linux-foundation.org> wrote:\n\n> You misunderstand. It would do so both for the newly merged commits *and* \n> for the old commits. Because _you_ think the \"new\" commits got merged, but \n> it's logically exactly equivalent to saying that the *old* commits got \n> merged.\n> \n> So now *every* single commit would get the timestamp of the merge.\n> \n> See? It would be pointless.\n\nOk maybe I am still confused. If a repository is in state A and a merge happens changing it to\nstate B we can give the changes that got us to B the timestamp of the merge? Since the changes\nthat got us from A to B were all merged locally at the same time they should be given the same\ntimestamp, right? Please explain more about how changes/commits in state A would also be given the\ntimestamp of the merge?\n\nWhen I say local time I also really mean local commit order as both should be interchangeable\nunless you widly misset/change your local clock. Git/gitweb could have an option to sort/display\nbased on local commit order and maybe have check for if local time order is out of sync with local\ncommit order.\n\n-Matt\n\n\n       \n____________________________________________________________________________________\nSick sense of humor? Visit Yahoo! TV's \nComedy with an Edge to see what's on, when. \nhttp://tv.yahoo.com/collections/222\n"},{"id":"49057","messageId":"Pine.LNX.4.64.0707292114120.6510@asgard.lang.hm","threadId":"9302","inReplyTo":"994493.95349.qm@web51001.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-07-30T04:17:56Z","receivedAt":"2007-07-30T04:17:56Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 29 Jul 2007, Matthew L Foster wrote:\n\n> --- Linus Torvalds <torvalds@linux-foundation.org> wrote:\n>\n>> You misunderstand. It would do so both for the newly merged commits *and*\n>> for the old commits. Because _you_ think the \"new\" commits got merged, but\n>> it's logically exactly equivalent to saying that the *old* commits got\n>> merged.\n>>\n>> So now *every* single commit would get the timestamp of the merge.\n>>\n>> See? It would be pointless.\n>\n> Ok maybe I am still confused. If a repository is in state A and a merge happens changing it to\n> state B we can give the changes that got us to B the timestamp of the merge? Since the changes\n> that got us from A to B were all merged locally at the same time they should be given the same\n> timestamp, right? Please explain more about how changes/commits in state A would also be given the\n> timestamp of the merge?\n>\n> When I say local time I also really mean local commit order as both should be interchangeable\n> unless you widly misset/change your local clock. Git/gitweb could have an option to sort/display\n> based on local commit order and maybe have check for if local time order is out of sync with local\n> commit order.\n\none feature of git (and I think of truely distributed change management \nsystems)\n\nsay you have tree A and I have tree B\n\nif you clone your tree and merge from mine, and I clone my tree and merge \nfrom yours, the result of both merges _must_ be the same there will be \ntrouble when we both try and merge with tree C later on.\n\nanother thing is that a given commit cannot be changed once it's created \n(if it was changed it wouldn't have the same sha1 value) so you can't just \ngo around changeing dates on commits that took place elsewhere.\n\nDavid Lang\n"},{"id":"49108","messageId":"153733.59721.qm@web51006.mail.re2.yahoo.com","threadId":"9302","inReplyTo":"Pine.LNX.4.64.0707292114120.6510@asgard.lang.hm","subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T16:20:00Z","receivedAt":"2007-07-30T16:20:00Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- david@lang.hm wrote:\n\n> if you clone your tree and merge from mine, and I clone my tree and merge \n> from yours, the result of both merges _must_ be the same there will be \n> trouble when we both try and merge with tree C later on.\n> \n> another thing is that a given commit cannot be changed once it's created \n> (if it was changed it wouldn't have the same sha1 value) so you can't just \n> go around changeing dates on commits that took place elsewhere.\n\nLocal commit order is stored locally right? From looking at gitweb on kernel.org it seems all the\ninfo is already there, a merge has a list of commits in that merge and they should be displayed in\nlocal commit order rather than external creation time order.\n\n-Matt\n\n\n\n       \n____________________________________________________________________________________Ready for the edge of your seat? \nCheck out tonight's top picks on Yahoo! TV. \nhttp://tv.yahoo.com/\n"},{"id":"49110","messageId":"Pine.LNX.4.64.0707300922420.11330@asgard.lang.hm","threadId":"9302","inReplyTo":"153733.59721.qm@web51006.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-07-30T16:23:50Z","receivedAt":"2007-07-30T16:23:50Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 30 Jul 2007, Matthew L Foster wrote:\n\n> --- david@lang.hm wrote:\n>\n>> if you clone your tree and merge from mine, and I clone my tree and merge\n>> from yours, the result of both merges _must_ be the same there will be\n>> trouble when we both try and merge with tree C later on.\n>>\n>> another thing is that a given commit cannot be changed once it's created\n>> (if it was changed it wouldn't have the same sha1 value) so you can't just\n>> go around changeing dates on commits that took place elsewhere.\n>\n> Local commit order is stored locally right?\n\nnot normally. you could enable reflogs and then mine through the reflogs \nto find the info, but it's not stored in any easy to access fashion.\n\nDavid Lang\n\n> From looking at gitweb on kernel.org it seems all the\n> info is already there, a merge has a list of commits in that merge and they should be displayed in\n> local commit order rather than external creation time order.\n>\n> -Matt\n>\n>\n>\n>\n> ____________________________________________________________________________________Ready for the edge of your seat?\n> Check out tonight's top picks on Yahoo! TV.\n> http://tv.yahoo.com/\n>\n"},{"id":"49114","messageId":"104942.93033.qm@web51008.mail.re2.yahoo.com","threadId":"9302","inReplyTo":"Pine.LNX.4.64.0707300922420.11330@asgard.lang.hm","subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T17:11:39Z","receivedAt":"2007-07-30T17:11:39Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\n--- david@lang.hm wrote:\n\n> On Mon, 30 Jul 2007, Matthew L Foster wrote:\n> > Local commit order is stored locally right?\n> \n> not normally. you could enable reflogs and then mine through the reflogs \n> to find the info, but it's not stored in any easy to access fashion.\n\nLocal merge order can be extracted from git? \n\n-Matt\n\n\n       \n____________________________________________________________________________________\nBe a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. \nhttp://answers.yahoo.com/dir/?link=list&sid=396545433\n"},{"id":"49116","messageId":"Pine.LNX.4.64.0707301013210.11330@asgard.lang.hm","threadId":"9302","inReplyTo":"104942.93033.qm@web51008.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-07-30T17:33:10Z","receivedAt":"2007-07-30T17:33:10Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 30 Jul 2007, Matthew L Foster wrote:\n\n> --- david@lang.hm wrote:\n>\n>> On Mon, 30 Jul 2007, Matthew L Foster wrote:\n>>> Local commit order is stored locally right?\n>>\n>> not normally. you could enable reflogs and then mine through the reflogs\n>> to find the info, but it's not stored in any easy to access fashion.\n>\n> Local merge order can be extracted from git?\n\nif you have reflogs enabled on your copy of the git repository then you \ncan look at when things were merged into your copy.\n\nDavid Lang\n"},{"id":"49157","messageId":"200707310011.10935.robin.rosenberg.lists@dewire.com","threadId":"9302","inReplyTo":"104942.93033.qm@web51008.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-07-30T22:11:09Z","receivedAt":"2007-07-30T22:11:09Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"måndag 30 juli 2007 skrev Matthew L Foster:\n> \n> --- david@lang.hm wrote:\n> \n> > On Mon, 30 Jul 2007, Matthew L Foster wrote:\n> > > Local commit order is stored locally right?\n> > \n> > not normally. you could enable reflogs and then mine through the reflogs \n> > to find the info, but it's not stored in any easy to access fashion.\n> \n> Local merge order can be extracted from git? \n\nWell.. depending on what your definition of merge. Yes, probably.\n\nI dislike the term \"merge\" here, since no merges has to be involved, unless you\ninclude any pulled commit into the terms. Normally a merge is a commit with\ntwo or more parents. Fast forward merges are indistinguishable from normal \ncommits.\n\nThat aside, you *can* (usually) figure the time when a commit entered the repository by examining the\nreflog if the set of branches are reasonably stable The reflog gives the local time when a head\nwas modified (old and new commit) so from there you can usually go backwards. *But* that road is\nfull of pot holes. The reflog cannot per se tell when a commit entered the local repo, it can\ntell when it came into view as seen from a particular head. Looking from different heads may\n(will) give you different times. If the head that was used to pull the commit into the repo is\ndeleted you will not be able to tell when the commit entered the repo, nor will you be able to\ntell whether you can tell that or not, since the reflog for that head is gone. \n\nThe reflog doesn't list all commits, just changes to the head and it isn't necessarily linear either, ie.\nit may change backward in \"time\" forward or even to a completely separate set of commits.\n\nThe reflog is text-only: .git/logs/<ref-name>, e.g. .git/logs/refs/heads/master so you can see for\nyourself.\n\n-- robin\n"}]}