{"thread":{"id":"39391","subject":"Occasional wrong behavior of rev-walking (rev-list, log, etc.)","startedAt":"2015-05-21T06:15:53Z","lastAt":"2015-05-22T00:57:53Z","messageCount":5,"participants":["Mike Hommey","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"261753","messageId":"20150521061553.GA29269@glandium.org","threadId":"39391","inReplyTo":null,"subject":"Occasional wrong behavior of rev-walking (rev-list, log, etc.)","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2015-05-21T06:15:53Z","receivedAt":"2015-05-21T06:15:53Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nI noticed that in some weird cases, git rev-list and friends would\nappear to not do their work as intended. As I wasn't entirely sure at\nthe time I saw previous occurrence (which involved lots of refs and\nbig history) , I kept that on the side to look back later, but today,\nit happened again on a somewhat smaller testcase, albeit, on a big\nrepository.\n\nI was able to reproduce it with the following:\n\n$ git clone https://github.com/mozilla/gecko-dev\n$ cd gecko-dev\n$ git checkout -b a 4d3f25020072867e19ad6d840a73c8d77ea040bd\n$ git commit --allow-empty -m a\n$ git checkout -b b e90de3e5e045428e8f2b732882736dc93ce05f14\n$ git commit --allow-empty -m b\n$ git merge a -m merge\n\nNow here's the problem:\n\n$ git rev-list e90de3e5e045428e8f2b732882736dc93ce05f14..b | wc -l\n86\n\nBut:\n$ git rev-list e90de3e5e045428e8f2b732882736dc93ce05f14 | grep 4d3f25020072867e19ad6d840a73c8d77ea040bd\n4d3f25020072867e19ad6d840a73c8d77ea040bd\n\nSo 4d3f25020072867e19ad6d840a73c8d77ea040bd is in\ne90de3e5e045428e8f2b732882736dc93ce05f14's history, which means the only\nthing that's on top of e90de3e5e045428e8f2b732882736dc93ce05f14 in b is\nthe 3 commits created above.\n\nMy guess is that rev-walking is tripping on the fact that this repository\nhas commit dates in random order.\n\nMike\n"},{"id":"261799","messageId":"xmqq617llw6k.fsf@gitster.dls.corp.google.com","threadId":"39391","inReplyTo":"20150521061553.GA29269@glandium.org","subject":"Re: Occasional wrong behavior of rev-walking (rev-list, log, etc.)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-21T16:41:55Z","receivedAt":"2015-05-21T16:41:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey <mh@glandium.org> writes:\n\n> My guess is that rev-walking is tripping on the fact that this repository\n> has commit dates in random order.\n\nYeah, that is well known (look for SLOP both in the code and list\narchive).\n"},{"id":"261863","messageId":"20150521224956.GA23810@glandium.org","threadId":"39391","inReplyTo":"xmqq617llw6k.fsf@gitster.dls.corp.google.com","subject":"Re: Occasional wrong behavior of rev-walking (rev-list, log, etc.)","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2015-05-21T22:49:56Z","receivedAt":"2015-05-21T22:49:56Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, May 21, 2015 at 09:41:55AM -0700, Junio C Hamano wrote:\n> Mike Hommey <mh@glandium.org> writes:\n> \n> > My guess is that rev-walking is tripping on the fact that this repository\n> > has commit dates in random order.\n> \n> Yeah, that is well known (look for SLOP both in the code and list\n> archive).\n\nI found the recent thread about git describe --contains. (and now I\nrealize this is also why git describe --contains doesn't work quite well\nfor the same repository).\n\nNow the question is what can we done in the short term? (short of\nintroducing something like generation numbers) I tried increasing\nSLOP and to remove the date check (with the hope that making one or\nboth configurable might help). Neither fixed the particular test\ncase I started this thread with.\n\nMike\n"},{"id":"261864","messageId":"CAPc5daVnrjdjoiq8-H7vs2WAre+Kt7J5re_kZ2YD9tF8dG8UUw@mail.gmail.com","threadId":"39391","inReplyTo":"20150521224956.GA23810@glandium.org","subject":"Re: Occasional wrong behavior of rev-walking (rev-list, log, etc.)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-21T22:59:48Z","receivedAt":"2015-05-21T22:59:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Depends on why you are running rev-list.\n\nIf you want to know if one commit is contained in another, the way\nthat should work the most reliably is to use merge-base, as the\ntraversal engine of that command was written not to trust the commit\ntimestamps but go with the topology alone.\n\n(pardon top-posting and overlong lines; typed in GMail)\n\n\nOn Thu, May 21, 2015 at 3:49 PM, Mike Hommey <mh@glandium.org> wrote:\n> On Thu, May 21, 2015 at 09:41:55AM -0700, Junio C Hamano wrote:\n>> Mike Hommey <mh@glandium.org> writes:\n>>\n>> > My guess is that rev-walking is tripping on the fact that this repository\n>> > has commit dates in random order.\n>>\n>> Yeah, that is well known (look for SLOP both in the code and list\n>> archive).\n>\n> I found the recent thread about git describe --contains. (and now I\n> realize this is also why git describe --contains doesn't work quite well\n> for the same repository).\n>\n> Now the question is what can we done in the short term? (short of\n> introducing something like generation numbers) I tried increasing\n> SLOP and to remove the date check (with the hope that making one or\n> both configurable might help). Neither fixed the particular test\n> case I started this thread with.\n>\n> Mike\n"},{"id":"261872","messageId":"20150522005753.GA2203@glandium.org","threadId":"39391","inReplyTo":"CAPc5daVnrjdjoiq8-H7vs2WAre+Kt7J5re_kZ2YD9tF8dG8UUw@mail.gmail.com","subject":"Re: Occasional wrong behavior of rev-walking (rev-list, log, etc.)","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2015-05-22T00:57:53Z","receivedAt":"2015-05-22T00:57:53Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, May 21, 2015 at 03:59:48PM -0700, Junio C Hamano wrote:\n> Depends on why you are running rev-list.\n> \n> If you want to know if one commit is contained in another, the way\n> that should work the most reliably is to use merge-base, as the\n> traversal engine of that command was written not to trust the commit\n> timestamps but go with the topology alone.\n\nSo, specifically, rev-list was just a side use-case that happened to\nshow the same problem (or at least appeared to) when I was looking at\nwhat the hell was happening. I should probably have started with my\nactual failure instead, sorry for that. So here it is in the form of\na testcase:\n\n$ git clone https://github.com/mozilla/gecko-dev\n$ cd gecko-dev\n$ git checkout -b a 4d3f25020072867e19ad6d840a73c8d77ea040bd\n$ git commit --allow-empty -m a\n$ git checkout -b b e90de3e5e045428e8f2b732882736dc93ce05f14\n$ git commit --allow-empty -m b\n$ git merge a -m merge\n$ git rebase -i e90de3e5e045428e8f2b732882736dc93ce05f14 b\n\nThis lists plenty of commits instead of just a and b, like what would\nhappen if there weren't timestamps skews.\n\nI've frequently used this kind of rebase in the past. It works most of\nthe time because the situation with timestamps is generally not a\nproblem. The reason I'm doing this kind of merge+rebase business is\nthat I have multiple topic branches that I need to rebase on top of each\nother before pushing them upstream, and it's actually simpler, command-\nwise, than actually rebasing the topics on top of each other.\n\nMike\n"}]}