Ambiguous sha-1 during a rebase

Ambiguous sha-1 during a rebase

[Mike Hommey]

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

Re: Ambiguous sha-1 during a rebase

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

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

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

Re: Ambiguous sha-1 during a rebase

[Mike Hommey]

On Wed, Apr 13, 2016 at 03:42:44PM -0700, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
> 
> > Should git-rebase use full sha-1s under the hood to avoid these type of
> > races?
> 
> It already should be doing so since Aug 2013, IIRC.

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

Mike

Re: Ambiguous sha-1 during a rebase

[Matthieu Moy]

Mike Hommey <mh@glandium.org> writes:

> On Wed, Apr 13, 2016 at 03:42:44PM -0700, Junio C Hamano wrote:
>> Mike Hommey <mh@glandium.org> writes:
>> 
>> > Should git-rebase use full sha-1s under the hood to avoid these type of
>> > races?
>> 
>> It already should be doing so since Aug 2013, IIRC.
>
> I'm using 2.8.1. Would there have been a regression?

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 ...

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Ambiguous sha-1 during a rebase

[Mike Hommey]

On Thu, Apr 14, 2016 at 11:09:06AM +0200, Matthieu Moy wrote:
> I suspect you did:
> 
> $ git rebase -i
> # editor pops up
> # switch to another terminal and fetch from elsewhere
> # close editor

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

> 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 ...

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

Re: Ambiguous sha-1 during a rebase

[Matthieu Moy]

Mike Hommey <mh@glandium.org> writes:

> 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,

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.

> 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.

Right.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Ambiguous sha-1 during a rebase

[Johannes Schindelin]

Hi Junio,

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

> Mike Hommey <mh@glandium.org> writes:
> 
> > Should git-rebase use full sha-1s under the hood to avoid these type of
> > races?
> 
> It already should be doing so since Aug 2013, IIRC.

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

Re: Ambiguous sha-1 during a rebase

[Remi Galan Alfonso]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Mike Hommey <mh@glandium.org> writes:
> 
> > 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,
> 
> 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.

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