Re: [PATCH 2/3] t3404: rebase: interactive: demonstrate short SHA-1 collision
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Aug 12, 2013, 07:40 UTC
- Message-ID
- <CAPig+cTYC-EPWFmqTxBO15PE6AuC3jUYNehtQwYk9oADp1AaZw@mail.gmail.com>
- In-Reply-To
- <7vzjsnzagj.fsf@alter.siamese.dyndns.org>
On Mon, Aug 12, 2013 at 2:31 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 53 quoted lines
> Eric Sunshine <sunshine@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 <sunshine@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.
Show 16 quoted lines
>> + 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