# [PATCH] gitweb: recognize six digit abbreviated SHA1 5 messages from 2009-01-13 to 2009-01-14. Participants: Anders Melchiorsen, Sam Vilain, Junio C Hamano. Thread: https://gitlist.dev/t/17130 ## Anders Melchiorsen, 2009-01-13 00:04 Subject: [PATCH] gitweb: recognize six digit abbreviated SHA1 Message-ID: <87mydw2hrb.fsf@cup.kalibalik.dk> URL: https://gitlist.dev/e/87mydw2hrb.fsf%40cup.kalibalik.dk ``` This lets gitweb hightlight abbreviated hashes as produced by git rev-parse --short. Signed-off-by: Anders Melchiorsen --- It seems like seven digit hashes are in vogue now. So, did I miss some reason for keeping it at eight in this spot? diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 0ac84d1..1a7d448 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -1337,7 +1337,7 @@ sub format_log_line_html { my $line = shift; $line = esc_html($line, -nbsp=>1); - if ($line =~ m/([0-9a-fA-F]{8,40})/) { + if ($line =~ m/([0-9a-fA-F]{7,40})/) { my $hash_text = $1; my $link = $cgi->a({-href => href(action=>"object", hash=>$hash_text), -- 1.6.0.2.514.g23abd3 ``` ## Anders Melchiorsen, 2009-01-13 00:08 Subject: Re: [PATCH] gitweb: recognize six digit abbreviated SHA1 Message-ID: <87mydw2hkb.fsf@cup.kalibalik.dk> URL: https://gitlist.dev/e/87mydw2hkb.fsf%40cup.kalibalik.dk In-Reply-To: <87mydw2hrb.fsf@cup.kalibalik.dk> ``` Anders Melchiorsen writes: > + if ($line =~ m/([0-9a-fA-F]{7,40})/) { I could not make up my mind between the seven digits from "git rev-parse --short" and the six digits currently used by gitk. So I put one option in the patch, and the other one in the subject. Cheers, Anders. ``` ## Sam Vilain, 2009-01-13 02:00 Subject: Re: [PATCH] gitweb: recognize six digit abbreviated SHA1 Message-ID: <496BF5D7.2090003@vilain.net> URL: https://gitlist.dev/e/496BF5D7.2090003%40vilain.net In-Reply-To: <87mydw2hkb.fsf@cup.kalibalik.dk> ``` Anders Melchiorsen wrote: > Anders Melchiorsen writes: > > >> + if ($line =~ m/([0-9a-fA-F]{7,40})/) { >> > > I could not make up my mind between the seven digits from "git > rev-parse --short" and the six digits currently used by gitk. > > So I put one option in the patch, and the other one in the subject. > I think if you're going to go so short as 6 digits, it's probably worth making sure that the really short SHA1s check commits only. eg, if you've got a commit 'fa023473' and a tree 'fa023421', then 'fa0234' should match the commit and not the tree. But I don't think there's a plumbing way to do a query like that at the moment. Even git.git isn't unique over 6 digits, even restricting to commits. Not since b0a3de ;-). Sam ``` ## Junio C Hamano, 2009-01-13 08:26 Subject: Re: [PATCH] gitweb: recognize six digit abbreviated SHA1 Message-ID: <7vd4erd32a.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vd4erd32a.fsf%40gitster.siamese.dyndns.org In-Reply-To: <496BF5D7.2090003@vilain.net> ``` Sam Vilain writes: > I think if you're going to go so short as 6 digits, it's probably worth > making sure that the really short SHA1s check commits only. eg, if > you've got a commit 'fa023473' and a tree 'fa023421', then 'fa0234' > should match the commit and not the tree. But I don't think there's a > plumbing way to do a query like that at the moment. When people give an abbreviated object name, 99% of the time they mean commits (and "index deadbeef..acebead" in a patch is a good place to pick blob object names from, which would be what the 99% of the remaining 1% would name), so making sure it is a commit or a blob would be a very sensible thing to do. Unfortunately, you fundamentally cannot do this without taking a performance hit of actually opening the object. ``` ## Sam Vilain, 2009-01-14 00:33 Subject: Re: [PATCH] gitweb: recognize six digit abbreviated SHA1 Message-ID: <496D32DD.9010303@vilain.net> URL: https://gitlist.dev/e/496D32DD.9010303%40vilain.net In-Reply-To: <7vd4erd32a.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano wrote: > When people give an abbreviated object name, 99% of the time they mean > commits (and "index deadbeef..acebead" in a patch is a good place to pick > blob object names from, which would be what the 99% of the remaining 1% > would name), so making sure it is a commit or a blob would be a very > sensible thing to do. > > Unfortunately, you fundamentally cannot do this without taking a > performance hit of actually opening the object. > Yeah. I envisioned this just for those cases where the tool would otherwise return 'ambiguous argument'; if there was a hint as to the object type, open *all* the matching objects and return the one that matched the type only. Sam. ```