Re: [BUG] rebase should desambiguate abbreviated hashes before starting

From: David <bouncingcats@gmail.com>
Date: Jun 27, 2013, 09:38 UTC
Message-ID: <CAMPXz=pSseQKebNVPVYogTZ2FUc1LqubgmS+pN76sveV=eqC0A@mail.gmail.com>
In-Reply-To: <20130627105513.6bf84060@chalon.bertin.fr>

On 27 June 2013 18:55, Yann Dirson <dirson@bertin.fr> wrote:

Show 7 quoted lines

> I just ran into a funny edge-case when doing a long rebase: one of
> the rewritten commits got a sha1 starting with one of the abbreviated
> sha1's of a commit still to be applied.
>
> As a result, the rebase stopped with a funny-looking "short SHA1 ... was
> ambiguous", which would not have occured if the shortened sha1's presented
> to the user were expanded to full sha1's before starting the rebase.

I do many large rebases, and I have experienced this about a dozen times in the last few years.

I'm not sure that rebase could predict the new hashes without actually creating the prior commits? So maybe the "short" SHA1 is "too short"?

When the rebase stops with this message, my workaround is:

The last (failed) entry is in .git/rebase-merge/done The next todo is the top entry in .git/rebase-merge/git-rebase-todo I enter the short SHA1 in gitk to find the long SHA1. I edit both the above files to move the failed entry back into the top of the todo file, with the long SHA1 And then git rebase --continue