On Mon, Aug 12, 2013 at 2:31 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
>
>> The 'todo' sheet for interactive rebase shows abbreviated SHA-1's and
>> then performs its operations upon those shortened values. This can lead
>> to an abort if the SHA-1 of a reworded or edited commit is no longer
>> unique within the abbreviated SHA-1 space and a subsequent SHA-1 in the
>> todo list has the same abbreviated value.
>>
>> For example:
>>
>> edit f00dfad first
>> pick badbeef second
>>
>> If, after editing, the new SHA-1 of "first" is now
>> badbeef5ba78983324dff5265c80c4490d5a809a, then the subsequent 'pick
>> badbeef second' will fail since badbeef is no longer a unique SHA-1
>> abbreviation:
>>
>> error: short SHA1 badbeef is ambiguous.
>> fatal: Needed a single revision
>> Invalid commit name: badbeef
>>
>> Demonstrate this problem with a couple of specially crafted commits
>> which initially have distinct abbreviated SHA-1's, but for which the
>> abbreviated SHA-1's collide after a simple rewording of the first
>> commit's message.
>>
>> Signed-off-by: Eric Sunshine <sunshine@xxxxxxxxxxxxxx>
>> ---
>> t/t3404-rebase-interactive.sh | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
>> index af141be..e5ebec6 100755
>> --- a/t/t3404-rebase-interactive.sh
>> +++ b/t/t3404-rebase-interactive.sh
>> @@ -977,4 +977,21 @@ test_expect_success 'rebase -i with --strategy and -X' '
>> test $(cat file1) = Z
>> '
>>
>> +test_expect_success 'short SHA-1 setup' '
>> + test_when_finished "git checkout master" &&
>> + git checkout --orphan collide &&
>> + git rm -rf . &&
>> + unset test_tick &&
>
> This will inconvenience tests added later to these two in the
> future. Oversight, or deliberate act knowing that these two are the
> last tests in this script ;-)?
>
> One bad thing is that "unset" loses information so that such future
> tests cannot resurrect test_tick and continue on from where the last
> test-tick left off.
Oversight. The commits were quite deliberately crafted with very
specific commit times, commit messages, trees, and blobs in order to
achieve a conflicting short SHA-1 ("badbeef") at rebase time, so it
was necessary to have test_tick at a known state.
It shouldn't be too much effort to save its value and restore it at
the end of the test.
>> + test_commit collide1 collide &&
>> + test_commit --notick collide2 collide &&
>> + test_commit --notick "collide3 115158b5" collide collide3 collide3
>> +'
>>
>> +test_expect_failure 'short SHA-1 collide' '
>> + test_when_finished "reset_rebase && git checkout master" &&
>> + git checkout collide &&
>> + FAKE_COMMIT_MESSAGE="collide2 815200e" \
>
> ;-)
>
>> + FAKE_LINES="reword 1 2" git rebase -i HEAD~2
>> +'
>> +
>> test_done
--
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