On Thu, Mar 8, 2012 at 11:48 AM, Thomas Rast <trast@xxxxxxxxxxx> wrote: > Dominique Quatravaux <domq@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html