{"thread":{"id":"42023","subject":"Ambiguous sha-1 during a rebase","startedAt":"2016-04-13T22:29:19Z","lastAt":"2016-04-14T17:27:04Z","messageCount":8,"participants":["Mike Hommey","Junio C Hamano","Matthieu Moy","Johannes Schindelin","Remi Galan Alfonso"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"283425","messageId":"20160413222919.GA10474@glandium.org","threadId":"42023","inReplyTo":null,"subject":"Ambiguous sha-1 during a rebase","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-04-13T22:29:19Z","receivedAt":"2016-04-13T22:29:19Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nSomething interesting happened to me. I was in the middle of an\ninteractive rebase, and after a --continue, I got:\n\nerror: short SHA1 e34ff55 is ambiguous.\nfatal: Needed a single revision\nInvalid commit name: e34ff55\n\nOne thing that happened, is that, while running that interactive rebase,\nI /also/ did a `git remote update` from an other shell, which, I guess,\nhappened to have imported another object that made e34ff55 ambiguous.\n\nShould git-rebase use full sha-1s under the hood to avoid these type of\nraces?\n\nRelatedly, having looked up the ambiguity, it turns out the other object\nthat fits the same short sha1 is a tree... maybe git should be able to\ndisambiguate in that case, since it was looking for a commit, and\nthere's only one commit with that short sha1?\n\nMike\n"},{"id":"283430","messageId":"xmqqr3e9i10b.fsf@gitster.mtv.corp.google.com","threadId":"42023","inReplyTo":"20160413222919.GA10474@glandium.org","subject":"Re: Ambiguous sha-1 during a rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-13T22:42:44Z","receivedAt":"2016-04-13T22:42:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> Should git-rebase use full sha-1s under the hood to avoid these type of\n> races?\n\nIt already should be doing so since Aug 2013, IIRC.\n"},{"id":"283432","messageId":"20160413225234.GA21602@glandium.org","threadId":"42023","inReplyTo":"xmqqr3e9i10b.fsf@gitster.mtv.corp.google.com","subject":"Re: Ambiguous sha-1 during a rebase","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-04-13T22:52:34Z","receivedAt":"2016-04-13T22:52:34Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Wed, Apr 13, 2016 at 03:42:44PM -0700, Junio C Hamano wrote:\n> Mike Hommey writes:\n> \n> > Should git-rebase use full sha-1s under the hood to avoid these type of\n> > races?\n> \n> It already should be doing so since Aug 2013, IIRC.\n\nI'm using 2.8.1. Would there have been a regression?\n\nMike\n"},{"id":"283438","messageId":"vpqr3e8wo99.fsf@anie.imag.fr","threadId":"42023","inReplyTo":"20160413225234.GA21602@glandium.org","subject":"Re: Ambiguous sha-1 during a rebase","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-04-14T09:09:06Z","receivedAt":"2016-04-14T09:09:06Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Mike Hommey writes:\n\n> On Wed, Apr 13, 2016 at 03:42:44PM -0700, Junio C Hamano wrote:\n>> Mike Hommey writes:\n>> \n>> > Should git-rebase use full sha-1s under the hood to avoid these type of\n>> > races?\n>> \n>> It already should be doing so since Aug 2013, IIRC.\n>\n> I'm using 2.8.1. Would there have been a regression?\n\nI guess you managed to get into a corner-case which isn't managed\nproperly. With my git version 2.8.1.53.g7ee34ab, I just checked the\nnormal use-case:\n\n$ git rebase -i HEAD^^\n\nThe editor pops up with short sha1. I insert a \"exec false\" like this:\n\n,----[ git-rebase-todo ]\n| pick 0c722f9 foo\n| exec false\n| pick 6305d56 commited\n`----\n\nThe execution goes on like this:\n\n Executing: false\n Execution failed: false\n You can fix the problem, and then run\n \n git rebase --continue\n \n\nAnd I can check:\n\n$ cat .git/rebase-merge/git-rebase-todo\npick 6305d56f7218b6f04451bab3ff27adb80dd6dad4 commited\n...\n\n\nI suspect you did:\n\n$ git rebase -i\n# editor pops up\n# switch to another terminal and fetch from elsewhere\n# close editor\n\nThen only, git turns short sha1s into long ones, and does not have the\ninformation to resolve ambiguities.\n\nWe could save a map (short -> long) before poping the editor and use\nthis map in priority when normalizing the todo-list to use long sha1s,\nbut we currently don't.\n\nBut I'm tempted to say that you just went very, very unlucky, and it's\nnot worth fixing ...\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"283441","messageId":"20160414093847.GA10852@glandium.org","threadId":"42023","inReplyTo":"vpqr3e8wo99.fsf@anie.imag.fr","subject":"Re: Ambiguous sha-1 during a rebase","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-04-14T09:38:47Z","receivedAt":"2016-04-14T09:38:47Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Apr 14, 2016 at 11:09:06AM +0200, Matthieu Moy wrote:\n> I suspect you did:\n> \n> $ git rebase -i\n> # editor pops up\n> # switch to another terminal and fetch from elsewhere\n> # close editor\n\nThat's possible, but I don't remember with certainty. At least it's\nplausible.\n\n> Then only, git turns short sha1s into long ones, and does not have the\n> information to resolve ambiguities.\n> \n> We could save a map (short -> long) before poping the editor and use\n> this map in priority when normalizing the todo-list to use long sha1s,\n> but we currently don't.\n> \n> But I'm tempted to say that you just went very, very unlucky, and it's\n> not worth fixing ...\n\nYeah, that definitely is a weird corner case. Interestingly, it was\ncomplaining about \"error: short SHA1 e34ff55 is ambiguous.\" when apply\n*other* commits that were in the list prior to it, and then had the\nfatal error when it reached it.\n\nThat said, that would be less likely to happen if disambiguation was\nalso checking checking the object type. Collisions between commits are\nless likely than between objects of different types.\n\nAs a matter of fact, of the 293143 commits in my repository, only 156\nhave collisions with other commits (0.05%), but when comparing them to\nall the 3260854 objects in the repository, I see 3545 have collisions\n(1.2%).\n\nMike\n"},{"id":"283445","messageId":"vpqa8kwtjbc.fsf@anie.imag.fr","threadId":"42023","inReplyTo":"20160414093847.GA10852@glandium.org","subject":"Re: Ambiguous sha-1 during a rebase","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-04-14T13:24:07Z","receivedAt":"2016-04-14T13:24:07Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Mike Hommey writes:\n\n> Yeah, that definitely is a weird corner case. Interestingly, it was\n> complaining about \"error: short SHA1 e34ff55 is ambiguous.\" when apply\n> *other* commits that were in the list prior to it,\n\nI think it did before: when normalizing the list to long sha1, i.e.\nright after you closed your editor and befor starting anything else.\n\n> That said, that would be less likely to happen if disambiguation was\n> also checking checking the object type. Collisions between commits are\n> less likely than between objects of different types.\n\nRight.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"283451","messageId":"alpine.DEB.2.20.1604141754371.2967@virtualbox","threadId":"42023","inReplyTo":"xmqqr3e9i10b.fsf@gitster.mtv.corp.google.com","subject":"Re: Ambiguous sha-1 during a rebase","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-04-14T15:55:34Z","receivedAt":"2016-04-14T15:55:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 13 Apr 2016, Junio C Hamano wrote:\n\n> Mike Hommey writes:\n> \n> > Should git-rebase use full sha-1s under the hood to avoid these type of\n> > races?\n> \n> It already should be doing so since Aug 2013, IIRC.\n\nIndeed. It is one of the things that makes interactive rebases so\nunbearably slow on Windows (because that transformation results in tons of\nspawned processes, which is slow on Windows, and even worse: tons of\nPOSIX-emulated processes, which is even slower).\n\nCiao,\nDscho\n"},{"id":"283459","messageId":"749683959.3734012.1460654824023.JavaMail.zimbra@ensimag.grenoble-inp.fr","threadId":"42023","inReplyTo":"vpqa8kwtjbc.fsf@anie.imag.fr","subject":"Re: Ambiguous sha-1 during a rebase","fromName":"Remi Galan Alfonso","fromEmail":"remi.galan-alfonso@ensimag.grenoble-inp.fr","sentAt":"2016-04-14T17:27:04Z","receivedAt":"2016-04-14T17:27:04Z","isPatch":false,"sender":{"key":"remi.galan-alfonso@ensimag.grenoble-inp.fr","avatar":"https://avatars.githubusercontent.com/u/12509162?v=4"},"body":"Matthieu Moy writes:\n> Mike Hommey writes:\n> \n> > Yeah, that definitely is a weird corner case. Interestingly, it was\n> > complaining about \"error: short SHA1 e34ff55 is ambiguous.\" when apply\n> > *other* commits that were in the list prior to it,\n> \n> I think it did before: when normalizing the list to long sha1, i.e.\n> right after you closed your editor and befor starting anything else.\n\nIn that case, I'm surprised that the rebase didn't stop before doing\nany action.\n\nI am guessing that the \"error: short SHA1 e34ff55 is ambiguous.\" is\ncomming from either 'check_commit_sha' called by 'check_todo_list' or\nby 'transform_todo_ids' called by 'expand_todo_ids'.\n\nIf my guess is correct {\n\n - If the former, it means that 'check_commit_sha' is not doing its\n job properly (it did not return an error code, which would have\n triggered a 'die' later and stopped the rebase at the beginning).\n\n - If the latter, it means that 'check_commit_sha' and\n 'check_todo_list' missed an occasion to error out.\n\n}\n\nOn a side note, is there a way to test for ambiguous SHA1?\n\nThanks,\nRémi\n"}]}