On Mon, Aug 12, 2013 at 2:31 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Eric Sunshine <sunsh...@sunshineco.com> 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 <sunsh...@sunshineco.com>
>> ---
>>  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to