{"thread":{"id":"38350","subject":"sporadic git failures on interactive rebase","startedAt":"2015-01-13T10:54:32Z","lastAt":"2015-01-14T21:57:55Z","messageCount":10,"participants":["Henning Moll","Jeff King","Junio C Hamano","Eric Sunshine"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"254601","messageId":"trinity-5098e61e-b59a-4225-9d4c-8879dc78bb53-1421146472532@3capp-gmx-bs08","threadId":"38350","inReplyTo":null,"subject":"sporadic git failures on interactive rebase","fromName":"Henning Moll","fromEmail":"newsscott@gmx.de","sentAt":"2015-01-13T10:54:32Z","receivedAt":"2015-01-13T10:54:32Z","isPatch":false,"sender":{"key":"newsscott@gmx.de","avatar":null},"body":"\nHi,\n\n(git version 2.2.0)\n\nI am currently developing/testing a script for a \"history surgery\" on a quite big repository (~30000 commits). The script always runs against exactly the same copy of a git repository. So things should be reproducable, but sometimes i get failures for the following sequence of commands:  \n\n$ git checkout some_branch\n$ GIT_SEQUENCE_EDITOR=\"sed -i '1s/^pick /edit /'\" git rebase -i $MERGETARGET~1\n$ git rm -rf some_files\n$ git commit --amend --no-edit -c $MERGETARGET\n$ git rebase --continue\n\n(where MERGETARGET is a valid commit id in the history of some_branch)\n\nHere is an example output where things went wrong (MERGETARGET is 6185ac39299a740dc9bc6c5906dd1f229b3f046b). The interesting parts are the messages \"c4095c1: not a commit that can be picked\" and \"error: short SHA1 c4095c1 is ambiguous.\":\n\n. Switched to branch 'master-flat'\n. c4095c1: not a commit that can be picked\n. 80f99bd: not a commit that can be picked\n. Stopped at 6185ac39299a740dc9bc6c5906dd1f229b3f046b... some_comment\n. You can amend the commit now, with\n. \n.         git commit --amend\n. \n. Once you are satisfied with your changes, run\n. \n.         git rebase --continue\n. rm 'some_files'\n. [detached HEAD 56675a06316345ac121997dde2b9eddb649d0539] some_comment\n.  Author: user <foo.bar@com.com>\n.  Date: Wed Sep 26 09:11:17 2012 +0000\n. [more info about that commit]\n. error: short SHA1 c4095c1 is ambiguous.\n. fatal: Needed a single revision\n. Invalid commit name: c4095c1\n\nNow that the command failed, i checked for ambigous c4095c1. But there is only one:\n$ git log -1 c4095c1\n. commit c4095c1f5e7c126accf93ba68e2fa72bb055f567\n. ...\n\nJust as a test:\n$ git log -1 c409\n. error: short SHA1 c409 is ambiguous.\n. error: short SHA1 c409 is ambiguous.\n\nAs i said above this issue is not strictly reproducable. I have a full backup of the working dir including the .git folder from just before the command sequence above. If i rollback and execute the commands again, everything works fine. Up to now i didn't had the situation the the sequence failed twice two in a row.\n\nI also have the backup of the directory from directly after the sequence failure. So i can still test some commands if you need more information.\n\nDoes anybody have an idea of what's going on here?\n\nBest regards\nHenning\n"},{"id":"254646","messageId":"20150114121915.GB30383@peff.net","threadId":"38350","inReplyTo":"trinity-5098e61e-b59a-4225-9d4c-8879dc78bb53-1421146472532@3capp-gmx-bs08","subject":"Re: sporadic git failures on interactive rebase","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-01-14T12:19:15Z","receivedAt":"2015-01-14T12:19:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 13, 2015 at 11:54:32AM +0100, Henning Moll wrote:\n\n> . error: short SHA1 c4095c1 is ambiguous.\n> . fatal: Needed a single revision\n> . Invalid commit name: c4095c1\n> \n> Now that the command failed, i checked for ambigous c4095c1. But there is only one:\n> $ git log -1 c4095c1\n> . commit c4095c1f5e7c126accf93ba68e2fa72bb055f567\n> . ...\n> \n> Just as a test:\n> $ git log -1 c409\n> . error: short SHA1 c409 is ambiguous.\n> . error: short SHA1 c409 is ambiguous.\n\nHmm. There are some instances in git where we know we are looking for an\nobject of a particular type, and we can disambiguate a short-sha1 based\non the type. And \"git log\" is just such a place, whereas a generic \"git\nrev-parse\" used by the git-rebase script would not be.\n\nTry:\n\n  git rev-list --objects --all |\n  grep ^c4095c1 |\n  cut -d' ' -f1 |\n  git cat-file --batch-check\n\nIf my hunch is right, then you may find multiple objects, only one of\nwhich is a commit.\n\nAnd if so, the solution is likely one of:\n\n  1. Teach rev-parse a \"prefer committish\" option and use it in the\n     appropriate spot in git-rebase.\n\n  2. Teach whatever is generating the shortended sha1s to report a truly\n     unambiguous result, not one that depends on the type. I don't think\n     we _have_ a codepath to do type-dependent shortening, though, which\n     is maybe an indication that this is a red herring.\n\nIt's also possible that part of the rebase sequence generates a new\nobject that creates the ambiguity. That would be consistent with your\nstatement that rolling back and running the commands again makes it\nwork. I'm not sure how to defend against that, aside from adding a\ncharacter or two to the shortened ids, which reduces the likelihood of a\ncollision.\n\n-Peff\n"},{"id":"254647","messageId":"20150114123536.GA31530@peff.net","threadId":"38350","inReplyTo":"20150114121915.GB30383@peff.net","subject":"Re: sporadic git failures on interactive rebase","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-01-14T12:35:36Z","receivedAt":"2015-01-14T12:35:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 14, 2015 at 07:19:15AM -0500, Jeff King wrote:\n\n> Hmm. There are some instances in git where we know we are looking for an\n> object of a particular type, and we can disambiguate a short-sha1 based\n> on the type. And \"git log\" is just such a place, whereas a generic \"git\n> rev-parse\" used by the git-rebase script would not be.\n> [...]\n>      I don't think\n>      we _have_ a codepath to do type-dependent shortening, though, which\n>      is maybe an indication that this is a red herring.\n\nYeah, I think this cannot be it. There is a 7-character commit/blob\nambiguity in git. You can find it yourself with:\n\n  git rev-list --objects --all |\n  cut -d' ' -f1 |\n  sort | uniq -w 7 -D |\n  git cat-file --batch-check |\n  head -2\n\nwhich produces:\n\n  01319837c53050109c60e6740dfa9462327161f0 commit 649\n  0131983dfbc143ce5dae77e067663bb2e7d5f126 blob 20638\n\nAnd it behaves as expected. Running \"git rev-parse 0131983\" complains of\nthe ambiguity, but \"git log 0131983\" shows the commit.\n\nWhat happens if we rebase with it?\n\n  $ git checkout 01319837\n  $ git rebase -i HEAD^\n\nwill yield a todo file with the 8-character unambiguous abbreviation.\n\nSo I guess all is working as intended there. Perhaps you really were\njust very unlucky and an earlier step of the rebase created a\nconflicting sha1.\n\n-Peff\n"},{"id":"254657","messageId":"xmqqvbk9b81d.fsf@gitster.dls.corp.google.com","threadId":"38350","inReplyTo":"20150114123536.GA31530@peff.net","subject":"Re: sporadic git failures on interactive rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-14T17:12:46Z","receivedAt":"2015-01-14T17:12:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> What happens if we rebase with it?\n>\n>   $ git checkout 01319837\n>   $ git rebase -i HEAD^\n>\n> will yield a todo file with the 8-character unambiguous abbreviation.\n>\n> So I guess all is working as intended there. Perhaps you really were\n> just very unlucky and an earlier step of the rebase created a\n> conflicting sha1.\n\nThat would mean 75c69766 (rebase -i: fix short SHA-1 collision,\n2013-08-23) did not fix what it intended to fix, no?  Is the symptom\ncoming from pre-1.8.4.2 version of Git?\n"},{"id":"254690","messageId":"20150114205437.GB1155@peff.net","threadId":"38350","inReplyTo":"xmqqvbk9b81d.fsf@gitster.dls.corp.google.com","subject":"Re: sporadic git failures on interactive rebase","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-01-14T20:54:37Z","receivedAt":"2015-01-14T20:54:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 14, 2015 at 09:12:46AM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > What happens if we rebase with it?\n> >\n> >   $ git checkout 01319837\n> >   $ git rebase -i HEAD^\n> >\n> > will yield a todo file with the 8-character unambiguous abbreviation.\n> >\n> > So I guess all is working as intended there. Perhaps you really were\n> > just very unlucky and an earlier step of the rebase created a\n> > conflicting sha1.\n> \n> That would mean 75c69766 (rebase -i: fix short SHA-1 collision,\n> 2013-08-23) did not fix what it intended to fix, no?  Is the symptom\n> coming from pre-1.8.4.2 version of Git?\n\nYeah, you're right. I didn't even remember that commit at all. On the\noff chance that the abbreviation code was different in that earlier\nversion, I also checked rebasing 01319837 with an older version, but it\ndoes work fine.\n\nSo yeah, the most plausible theory to me so far is unluckiness combined\nwith pre-1.8.4.2. That should be easy to disprove if Henning tells us\nhis git version.\n\n-Peff\n"},{"id":"254692","messageId":"CAPig+cQ9GpL9r6Rr96jc6G=EvCArodSXC-qMzSBp=e7c7QQbtA@mail.gmail.com","threadId":"38350","inReplyTo":"20150114205437.GB1155@peff.net","subject":"Re: sporadic git failures on interactive rebase","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-01-14T21:00:37Z","receivedAt":"2015-01-14T21:00:37Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Jan 14, 2015 at 3:54 PM, Jeff King <peff@peff.net> wrote:\n> On Wed, Jan 14, 2015 at 09:12:46AM -0800, Junio C Hamano wrote:\n>\n>> Jeff King <peff@peff.net> writes:\n>>\n>> > What happens if we rebase with it?\n>> >\n>> >   $ git checkout 01319837\n>> >   $ git rebase -i HEAD^\n>> >\n>> > will yield a todo file with the 8-character unambiguous abbreviation.\n>> >\n>> > So I guess all is working as intended there. Perhaps you really were\n>> > just very unlucky and an earlier step of the rebase created a\n>> > conflicting sha1.\n>>\n>> That would mean 75c69766 (rebase -i: fix short SHA-1 collision,\n>> 2013-08-23) did not fix what it intended to fix, no?  Is the symptom\n>> coming from pre-1.8.4.2 version of Git?\n>\n> Yeah, you're right. I didn't even remember that commit at all. On the\n> off chance that the abbreviation code was different in that earlier\n> version, I also checked rebasing 01319837 with an older version, but it\n> does work fine.\n>\n> So yeah, the most plausible theory to me so far is unluckiness combined\n> with pre-1.8.4.2. That should be easy to disprove if Henning tells us\n> his git version.\n\nHenning mentioned it at the very top of his original problem report:\n\n    \"(git version 2.2.0)\"\n"},{"id":"254694","messageId":"CAPig+cSAbo0NJP4+NS7=vfhqL4KzWFiYX6mzESnp1HkSEeFVUw@mail.gmail.com","threadId":"38350","inReplyTo":"CAPig+cQ9GpL9r6Rr96jc6G=EvCArodSXC-qMzSBp=e7c7QQbtA@mail.gmail.com","subject":"Re: sporadic git failures on interactive rebase","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-01-14T21:02:03Z","receivedAt":"2015-01-14T21:02:03Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Jan 14, 2015 at 4:00 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:\n> On Wed, Jan 14, 2015 at 3:54 PM, Jeff King <peff@peff.net> wrote:\n>> On Wed, Jan 14, 2015 at 09:12:46AM -0800, Junio C Hamano wrote:\n>>\n>>> Jeff King <peff@peff.net> writes:\n>>>\n>>> > What happens if we rebase with it?\n>>> >\n>>> >   $ git checkout 01319837\n>>> >   $ git rebase -i HEAD^\n>>> >\n>>> > will yield a todo file with the 8-character unambiguous abbreviation.\n>>> >\n>>> > So I guess all is working as intended there. Perhaps you really were\n>>> > just very unlucky and an earlier step of the rebase created a\n>>> > conflicting sha1.\n>>>\n>>> That would mean 75c69766 (rebase -i: fix short SHA-1 collision,\n>>> 2013-08-23) did not fix what it intended to fix, no?  Is the symptom\n>>> coming from pre-1.8.4.2 version of Git?\n>>\n>> Yeah, you're right. I didn't even remember that commit at all. On the\n>> off chance that the abbreviation code was different in that earlier\n>> version, I also checked rebasing 01319837 with an older version, but it\n>> does work fine.\n>>\n>> So yeah, the most plausible theory to me so far is unluckiness combined\n>> with pre-1.8.4.2. That should be easy to disprove if Henning tells us\n>> his git version.\n>\n> Henning mentioned it at the very top of his original problem report:\n>\n>     \"(git version 2.2.0)\"\n\nFor completeness: http://article.gmane.org/gmane.comp.version-control.git/262334\n"},{"id":"254695","messageId":"20150114210222.GA5396@peff.net","threadId":"38350","inReplyTo":"CAPig+cQ9GpL9r6Rr96jc6G=EvCArodSXC-qMzSBp=e7c7QQbtA@mail.gmail.com","subject":"Re: sporadic git failures on interactive rebase","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-01-14T21:02:22Z","receivedAt":"2015-01-14T21:02:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 14, 2015 at 04:00:37PM -0500, Eric Sunshine wrote:\n\n> > So yeah, the most plausible theory to me so far is unluckiness combined\n> > with pre-1.8.4.2. That should be easy to disprove if Henning tells us\n> > his git version.\n> \n> Henning mentioned it at the very top of his original problem report:\n> \n>     \"(git version 2.2.0)\"\n\nAh, reading comprehension. It pays off.\n\nI'm stumped, then.\n\n-Peff\n"},{"id":"254697","messageId":"CAPig+cT+bG=Pzws0WKpgnZX2mg4+VmAgxTBCwNiOGDmY4AzSKQ@mail.gmail.com","threadId":"38350","inReplyTo":"20150114210222.GA5396@peff.net","subject":"Re: sporadic git failures on interactive rebase","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-01-14T21:11:09Z","receivedAt":"2015-01-14T21:11:09Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Jan 14, 2015 at 4:02 PM, Jeff King <peff@peff.net> wrote:\n> On Wed, Jan 14, 2015 at 04:00:37PM -0500, Eric Sunshine wrote:\n>\n>> > So yeah, the most plausible theory to me so far is unluckiness combined\n>> > with pre-1.8.4.2. That should be easy to disprove if Henning tells us\n>> > his git version.\n>>\n>> Henning mentioned it at the very top of his original problem report:\n>>\n>>     \"(git version 2.2.0)\"\n>\n> Ah, reading comprehension. It pays off.\n>\n> I'm stumped, then.\n\nPerhaps some new code been added to git-rebase--interactive.sh since\n75c69766 which neglects to invoke expand_todo_ids()?\n\nOr, possibly some older version of git is being invoked somehow during\nrebase despite his \"front end\" use of 2.2.0?\n"},{"id":"254701","messageId":"xmqqoaq181p8.fsf@gitster.dls.corp.google.com","threadId":"38350","inReplyTo":"CAPig+cT+bG=Pzws0WKpgnZX2mg4+VmAgxTBCwNiOGDmY4AzSKQ@mail.gmail.com","subject":"Re: sporadic git failures on interactive rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-14T21:57:55Z","receivedAt":"2015-01-14T21:57:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine <sunshine@sunshineco.com> writes:\n\n> On Wed, Jan 14, 2015 at 4:02 PM, Jeff King <peff@peff.net> wrote:\n>> On Wed, Jan 14, 2015 at 04:00:37PM -0500, Eric Sunshine wrote:\n>>\n>>> > So yeah, the most plausible theory to me so far is unluckiness combined\n>>> > with pre-1.8.4.2. That should be easy to disprove if Henning tells us\n>>> > his git version.\n>>>\n>>> Henning mentioned it at the very top of his original problem report:\n>>>\n>>>     \"(git version 2.2.0)\"\n>>\n>> Ah, reading comprehension. It pays off.\n>>\n>> I'm stumped, then.\n>\n> Perhaps some new code been added to git-rebase--interactive.sh since\n> 75c69766 which neglects to invoke expand_todo_ids()?\n>\n> Or, possibly some older version of git is being invoked somehow during\n> rebase despite his \"front end\" use of 2.2.0?\n\nOr git_sequence_editor creates conflicting objects?\n"}]}