From: Dominique Quatravaux Date: Thu, 08 Mar 2012 11:48:24 GMT Subject: Re: [PATCH 1/2] rebase -i: optimize the creation of the todo file Message-ID: In-Reply-To: <87boo7pdvc.fsf@thomas.inf.ethz.ch> On Thu, Mar 8, 2012 at 11:48 AM, Thomas Rast wrote: > Dominique Quatravaux 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