From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Tue, 03 Feb 2009 12:31:44 GMT
Subject: Re: webgit highlightes mem adresses as git versions
Message-ID: <alpine.DEB.1.00.0902031327340.6573@intel-tinevez-2-302>
In-Reply-To: <200902031204.21435.toralf.foerster@gmx.de>

Hi,

On Tue, 3 Feb 2009, Toralf Förster wrote:

> At Monday 02 February 2009 23:54:20 Jakub Narebski wrote :
> > Toralf Förster <toralf.foerster@gmx.de> writes:
> > > As seen here
> > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=com
> > >mit;h=8ca2918f99b5861359de1805f27b08023c82abd2 the strings [<c043d0f3>]
> > > and firends shouldn't be recognized as git hashes, isn't it ?
> >
> > Gitweb, not webgit.  And gitweb considers ([0-9a-fA-F]{8,40}) i.e.
> > from 8 to 40 hexadecimal characters to be (shortened) SHA-1.  It
> > simply cannot afford checking if such object exists when displaying
> > commit message (for example in 'log' view).
> 
> Ah - ok, what's about expecting spaces around such SHA-1 keys ?

Won't fly: there was a recommendation at some point that you should refer 
to commits in such a form:

	2819075(Merge branch 'maint-1.6.0' into maint)

However, gitweb being written in Perl, I think a lookbehind like (?<!0x), 
i.e. that a 0x in front of the hexadecimal characters means it is no 
SHA-1.

Even better would be using word boundaries, I guess, but all that fails 
when you have a hexdump in the commit message.

Ciao,
Dscho