Mike Hommey <mh@xxxxxxxxxxxx> writes:
> On Wed, Apr 13, 2016 at 03:42:44PM -0700, Junio C Hamano wrote:
>> Mike Hommey <mh@xxxxxxxxxxxx> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html