Re: [PATCH 1/2] rebase -i: optimize the creation of the todo file
- From
Dominique Quatravaux <domq@google.com>
- Date
- Mar 8, 2012, 11:48 UTC
- Message-ID
- <CAJh6GrGWfyKguhgf9dJR4yG3qYjh2jJz7OzzN8wao0rWLcohoA@mail.gmail.com>
- In-Reply-To
- <87boo7pdvc.fsf@thomas.inf.ethz.ch>
On Thu, Mar 8, 2012 at 11:48 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
Show 7 quoted lines
> 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.
Show 18 quoted lines
> 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