Re: git blame gives an ambiguous short revision

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 2, 2012, 07:17 UTC
Message-ID: <7vipe63a4r.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.2.02.1207010825370.1873@hadrien>

Julia Lawall <julia.lawall@lip6.fr> writes:

Show 22 quoted lines

> Using linux-next cloned today (July 1), I then checkout out the
> revision 60d5c9f5b.  The command
>
> git blame drivers/staging/brcm80211/brcmfmac/wl_iw.c -L3675,3675
>
> then gives:
>
> 60d5c9f5 (Julia Lawall 2011-04-01 16:23:42 +0200 3675)  if (!iscan->iscan_ex_params_p) {
>
> Then I try:
>
> git show 60d5c9f5
>
> which gives:
>
> error: short SHA1 60d5c9f5 is ambiguous.
> error: short SHA1 60d5c9f5 is ambiguous.
> fatal: ambiguous argument '60d5c9f5': unknown revision or path not in the
> working tree.
> Use '--' to separate paths from revisions
>
> If I give git blame the -l option, every thing is fine.

Or you can use --abbrev to explicitly set the width; as the length necessary to make the abbreviated object names depends on the project, there is no good default.

I think it should be an easy patch to add a post-processing phase after all lines are blamed to automatically compute an appropriate value of abbreviation to ensure the uniqueness, but the current blame output does not bother to do so.