Ambiguous sha-1 during a rebase

Hi,

Something interesting happened to me. I was in the middle of an interactive rebase, and after a --continue, I got:

error: short SHA1 e34ff55 is ambiguous. fatal: Needed a single revision Invalid commit name: e34ff55

One thing that happened, is that, while running that interactive rebase, I /also/ did a `git remote update` from an other shell, which, I guess, happened to have imported another object that made e34ff55 ambiguous.

Should git-rebase use full sha-1s under the hood to avoid these type of races?

Relatedly, having looked up the ambiguity, it turns out the other object that fits the same short sha1 is a tree... maybe git should be able to disambiguate in that case, since it was looking for a commit, and there's only one commit with that short sha1?

Mike

Mike Hommey <mh@glandium.org> writes:

It already should be doing so since Aug 2013, IIRC.

On Wed, Apr 13, 2016 at 03:42:44PM -0700, Junio C Hamano wrote:

I'm using 2.8.1. Would there have been a regression?

Mike

Mike Hommey <mh@glandium.org> writes:

I guess you managed to get into a corner-case which isn't managed properly. With my git version 2.8.1.53.g7ee34ab, I just checked the normal use-case:

$ git rebase -i HEAD^^

The editor pops up with short sha1. I insert a "exec false" like this:

,----[ git-rebase-todo ]
| pick 0c722f9 foo
| exec false
| pick 6305d56 commited
`----

The execution goes on like this:

  Executing: false
  Execution failed: false
  You can fix the problem, and then run
  
          git rebase --continue
  

And I can check:

$ cat .git/rebase-merge/git-rebase-todo pick 6305d56f7218b6f04451bab3ff27adb80dd6dad4 commited ...

I suspect you did:

$ git rebase -i # editor pops up # switch to another terminal and fetch from elsewhere # close editor

Then only, git turns short sha1s into long ones, and does not have the information to resolve ambiguities.

We could save a map (short -> long) before poping the editor and use this map in priority when normalizing the todo-list to use long sha1s, but we currently don't.

But I'm tempted to say that you just went very, very unlucky, and it's not worth fixing ...

On Thu, Apr 14, 2016 at 11:09:06AM +0200, Matthieu Moy wrote:

That's possible, but I don't remember with certainty. At least it's plausible.

Yeah, that definitely is a weird corner case. Interestingly, it was complaining about "error: short SHA1 e34ff55 is ambiguous." when apply *other* commits that were in the list prior to it, and then had the fatal error when it reached it.

That said, that would be less likely to happen if disambiguation was also checking checking the object type. Collisions between commits are less likely than between objects of different types.

As a matter of fact, of the 293143 commits in my repository, only 156 have collisions with other commits (0.05%), but when comparing them to all the 3260854 objects in the repository, I see 3545 have collisions (1.2%).

Mike

Mike Hommey <mh@glandium.org> writes:

I think it did before: when normalizing the list to long sha1, i.e. right after you closed your editor and befor starting anything else.

Right.

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

In that case, I'm surprised that the rebase didn't stop before doing any action.

I am guessing that the "error: short SHA1 e34ff55 is ambiguous." is comming from either 'check_commit_sha' called by 'check_todo_list' or by 'transform_todo_ids' called by 'expand_todo_ids'.

If my guess is correct {

 - If the former, it means that 'check_commit_sha' is not doing its
   job properly (it did not return an error code, which would have
   triggered a 'die' later and stopped the rebase at the beginning).

 - If the latter, it means that 'check_commit_sha' and
   'check_todo_list' missed an occasion to error out.

}

On a side note, is there a way to test for ambiguous SHA1?

Thanks, Rémi

Hi Junio,

On Wed, 13 Apr 2016, Junio C Hamano wrote:

Indeed. It is one of the things that makes interactive rebases so unbearably slow on Windows (because that transformation results in tons of spawned processes, which is slow on Windows, and even worse: tons of POSIX-emulated processes, which is even slower).

Ciao, Dscho