Re: [PATCH 1/2] rebase -i: optimize the creation of the todo file

[Dominique Quatravaux <domq@google.com>]

On Thu, Mar 8, 2012 at 11:48 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
> Dominique Quatravaux <domq@google.com> writes:
>
>> Instead of obtaining short SHA1's from "git rev-list" and hitting the repository
>> once more with "git rev-parse" for the full-size SHA1's, obtain long SHA1's from
>> "git rev-list" and truncate them with "cut".
>
> That doesn't work if there are 7-digit SHA1 collisions in the repo.

I don't see how my patch changes the picture wrt SHA1 collisions. In
the current state, the rebase todo already uses short SHA1s.

> Even my git.git has a bunch of them, as checked with
>
>  git rev-list --objects --all | cut -c1-7 | sort | uniq -d
>
> and I expect a bigger project would have collisions beyond the 9th
> digit.
>
> What you can, however, do:
>
>> -git rev-list $merges_option --pretty=oneline --abbrev-commit \
>> -     --abbrev=7 --reverse --left-right --topo-order \
>> +git rev-list $merges_option --pretty=oneline --no-abbrev-commit \
>> +     --reverse --left-right --topo-order \
>>       $revisions | \
>
> rev-list can give you *both* the abbreviated and full SHA1s if you say
>
>  git rev-list $merges_option --format="%>%h %H %s" <...etc...>

Interesting, thanks! It seems that %h works with find_unique_abbrev
which according to the name, should Do The Right Thing. I'll update my
patch.


-- 
  Dominique Quatravaux
  +41 79 609 40 72