{"thread":{"id":"47575","subject":"merge-base --is-ancestor A B is unreasonably slow with unrelated history B","startedAt":"2018-01-09T15:17:51Z","lastAt":"2018-01-10T14:01:33Z","messageCount":4,"participants":["Ævar Arnfjörð Bjarmason","Junio C Hamano","Derrick Stolee"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"336260","messageId":"87608bawoa.fsf@evledraar.gmail.com","threadId":"47575","inReplyTo":null,"subject":"merge-base --is-ancestor A B is unreasonably slow with unrelated history B","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-01-09T15:17:41Z","receivedAt":"2018-01-09T15:17:51Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"This is a pathological case I don't have time to dig into right now:\n\n    git branch -D orphan;\n    git checkout --orphan orphan &&\n    git reset --hard &&\n    touch foo &&\n    git add foo &&\n    git commit -m\"foo\" &&\n    time git merge-base --is-ancestor master orphan\n\nThis takes around 5 seconds on linux.git to return 1. Which is around\nthe same time it takes to run current master against the first commit in\nlinux.git:\n\n    git merge-base --is-ancestor 1da177e4c3f4 master\n\nThis is obviously a pathological case, but maybe we should work slightly\nharder on the RHS of and discover that it itself is an orphan commit.\n\nI ran into this while writing a hook where we'd like to do:\n\n    git diff $master...topic\n\nOr not, depending on if the topic is an orphan or just something\nrecently branched off, figured I could use --is-ancestor as on\noptimization, and then discovered it's not much of an optimization.\n"},{"id":"336297","messageId":"xmqq7esq6e2g.fsf@gitster.mtv.corp.google.com","threadId":"47575","inReplyTo":"87608bawoa.fsf@evledraar.gmail.com","subject":"Re: merge-base --is-ancestor A B is unreasonably slow with unrelated history B","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-01-09T19:13:11Z","receivedAt":"2018-01-09T19:13:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> This is obviously a pathological case, but maybe we should work slightly\n> harder on the RHS of and discover that it itself is an orphan commit.\n\nIn order to discover a commit is an orphan, you'd need to prove not\njust that it does not reach the main part of the history (which is\ncheap---its parenthood network would be quite limited and traversing\nall of it is not that expensive) but the other way around, i.e. the\nmain part of the history would not reach it.\n\nDo you have a cheaper way to do the latter than a full traveral of\nthe main history?  If not, then the cost similar to \"git log master\"\nis expected.\n"},{"id":"336304","messageId":"2aa20617-6b1d-f5a4-d6e1-250a3ea8f5be@gmail.com","threadId":"47575","inReplyTo":"87608bawoa.fsf@evledraar.gmail.com","subject":"Re: merge-base --is-ancestor A B is unreasonably slow with unrelated history B","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2018-01-09T19:30:59Z","receivedAt":"2018-01-09T19:31:06Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 1/9/2018 10:17 AM, Ævar Arnfjörð Bjarmason wrote:\n> This is a pathological case I don't have time to dig into right now:\n>\n>      git branch -D orphan;\n>      git checkout --orphan orphan &&\n>      git reset --hard &&\n>      touch foo &&\n>      git add foo &&\n>      git commit -m\"foo\" &&\n>      time git merge-base --is-ancestor master orphan\n>\n> This takes around 5 seconds on linux.git to return 1. Which is around\n> the same time it takes to run current master against the first commit in\n> linux.git:\n>\n>      git merge-base --is-ancestor 1da177e4c3f4 master\n>\n> This is obviously a pathological case, but maybe we should work slightly\n> harder on the RHS of and discover that it itself is an orphan commit.\n>\n> I ran into this while writing a hook where we'd like to do:\n>\n>      git diff $master...topic\n>\n> Or not, depending on if the topic is an orphan or just something\n> recently branched off, figured I could use --is-ancestor as on\n> optimization, and then discovered it's not much of an optimization.\n\nÆvar,\n\nThis is the same performance problem that we are trying to work around \nwith Jeff's \"Add --no-ahead-behind to status\" patch [1]. For commits \nthat are far apart, many commits need to be parsed. I think the right \nsolution is to create a serialized commit graph that stores the \nadjacency information of the commits and can create commit structs \nquickly. This requires storing the commit id, commit date, parents, and \nroot tree id to satisfy the needs of parse_commit_gently(). Once the \nframework for this data is constructed, it is simple to add generation \nnumbers to that data and start consuming them in other algorithms (by \nadding the field to 'struct commit').\n\nI'm working on such a patch right now, but it will be a few weeks before \nI'm ready.\n\nThanks,\n-Stolee\n\n[1] v5 of --no-ahead-behind \nhttps://public-inbox.org/git/20180109185018.69164-1-git@jeffhostetler.com/T/#t\n\n[2] v4 of --no-ahead-behind \nhttps://public-inbox.org/git/nycvar.QRO.7.76.6.1801091744540.37@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz/T/#t\n\n\n"},{"id":"336380","messageId":"87o9m1ak3x.fsf@evledraar.gmail.com","threadId":"47575","inReplyTo":"2aa20617-6b1d-f5a4-d6e1-250a3ea8f5be@gmail.com","subject":"Re: merge-base --is-ancestor A B is unreasonably slow with unrelated history B","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-01-10T14:01:22Z","receivedAt":"2018-01-10T14:01:33Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Jan 09 2018, Derrick Stolee jotted:\n\n> On 1/9/2018 10:17 AM, Ævar Arnfjörð Bjarmason wrote:\n>> This is a pathological case I don't have time to dig into right now:\n>>\n>>      git branch -D orphan;\n>>      git checkout --orphan orphan &&\n>>      git reset --hard &&\n>>      touch foo &&\n>>      git add foo &&\n>>      git commit -m\"foo\" &&\n>>      time git merge-base --is-ancestor master orphan\n>>\n>> This takes around 5 seconds on linux.git to return 1. Which is around\n>> the same time it takes to run current master against the first commit in\n>> linux.git:\n>>\n>>      git merge-base --is-ancestor 1da177e4c3f4 master\n>>\n>> This is obviously a pathological case, but maybe we should work slightly\n>> harder on the RHS of and discover that it itself is an orphan commit.\n>>\n>> I ran into this while writing a hook where we'd like to do:\n>>\n>>      git diff $master...topic\n>>\n>> Or not, depending on if the topic is an orphan or just something\n>> recently branched off, figured I could use --is-ancestor as on\n>> optimization, and then discovered it's not much of an optimization.\n>\n> Ævar,\n>\n> This is the same performance problem that we are trying to work around\n> with Jeff's \"Add --no-ahead-behind to status\" patch [1]. For commits\n> that are far apart, many commits need to be parsed. I think the right\n> solution is to create a serialized commit graph that stores the\n> adjacency information of the commits and can create commit structs\n> quickly. This requires storing the commit id, commit date, parents,\n> and root tree id to satisfy the needs of parse_commit_gently(). Once\n> the framework for this data is constructed, it is simple to add\n> generation numbers to that data and start consuming them in other\n> algorithms (by adding the field to 'struct commit').\n>\n> I'm working on such a patch right now, but it will be a few weeks\n> before I'm ready.\n\nThanks, yes of course I forgot about not being able to rely on\ntimestamps at all, otherwise this check wouldn't need commit traversal\nat all, we could simply note:\n\n 1. A is older than B\n 2. B is an orphan commit\n 3. Therefore it's impossible that A is an ancestor of B\n\nBut we don't enforce any of this in the DAG, so now we need to do a full\ntraversal to make sure this B committed in 2018 doesn't precede some\ncommit added in 2005.\n\nThis has come up before related to various traversal optimizations,\ne.g. [tag|branch] --contains.\n\nI don't know the details of what you have in mind, but have you\nconsidered a solution which involves either computing that all commits\nin the repo have a timestamp later than their parents, or alternatively\ndeclaring via some config mechanism that that's true of all (or a subset\nof) commits?\n\nE.g. for centrally hosted repos a pre-receive hook could be added to\nassert that all incoming commits must have monotonically increasing\ntimestamps compared to preceding commits, and if that wasn't the case we\ncould declare that e.g. all commits added after 2019 would have that\nproperty (after ensuring no commits had dates in the future).\n\nIt sounds like a subset of what you have in mind, so maybe it's\nuseless. However for many cases such as this one it should be faster to\nalmost instantaneously consult such config instead of some side-data we\nneed to maintain, but it's probably not worth the complexity.\n\n\n> [1] v5 of --no-ahead-behind\n> https://public-inbox.org/git/20180109185018.69164-1-git@jeffhostetler.com/T/#t\n>\n> [2] v4 of --no-ahead-behind\n> https://public-inbox.org/git/nycvar.QRO.7.76.6.1801091744540.37@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz/T/#t\n"}]}