Ævar Arnfjörð Bjarmason <[email protected]> writes:
> As far as I can tell the only outstanding "change this" is your
> s/SHA1/SHA-1/ in <[email protected]>, do
> you want to fix that up or should I submit another series?
I think I did that already myself while queuing. Could you fetch
what I queued on 'pu' to double check?
I think the diff between what was posted and what is queued (I just
checked) looks like this:
-gitweb: Link to 7-char+ SHA1s, not only 8-char+
+gitweb: link to 7-char+ SHA-1s, not only 8-char+
Change the minimum length of an abbreviated object identifier in the
commit message gitweb tries to turn into link from 8 hexchars to 7.
@@ -5,16 +12,18 @@
SHA-1 in commit log message links to "object" view", 2006-12-10), but
the default abbreviation length is 7, and has been for a long time.
-It's still possible to reference SHA1s down to 4 characters in length,
+It's still possible to reference SHA-1s down to 4 characters in length,
see v1.7.4-1-gdce9648's MINIMUM_ABBREV, but I can't see how to make
git actually produce that, so I doubt anyone is putting that into log
-messages in practice, but people definitely do put 7 character SHA1s
+messages in practice, but people definitely do put 7 character SHA-1s
into log messages.
I think it's fairly dubious to link to things matching [0-9a-fA-F]
here as opposed to just [0-9a-f], that dates back to the initial
version of gitweb from 161332a ("first working version",
-2005-08-07). Git will accept all-caps SHA1s, but didn't ever produce
+2005-08-07). Git will accept all-caps SHA-1s, but didn't ever produce
them as far as I can tell.
Signed-off-by: Ævar Arnfjörð Bjarmason <[email protected]>
+Acked-by: Jakub Narębski <[email protected]>
+Signed-off-by: Junio C Hamano <[email protected]>
