Re: [PATCH v2 3/3] gitweb: Link to "git describe"'d commits in log messages

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 14, 2016, 19:00 UTC
Message-ID: <xmqqvawuycv0.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACBZZX4HPci=n193WPm1RCes4PZfFXQtAdJuwxMwvTvF2NBVMA@mail.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 11 quoted lines

> I just ran into an example of a better reason for doing it like my
> patch is doing, which is that if you have some tag like:
>
> deployment-20160928-171914-16-g42e13d8
>
> With my patch the whole thing will be a link to the 42e13d8 commit,
> but with this suggestion both 20160928 and 42e13d8 would become commit
> links, the former one would be broken.
>
> Of course we could have some code that would detect that the whole \S+
> is part of one thing that ends in g<commit>,...

I think that this example shows a flaw not in the "suffix that looks like an object name" approach, but more in the boundary regexp, namely, the \b part; it is probably too loose.

And \S+ is not the right cue, either, for that matter. IOW, "we only should take hexstring, optionally prefixed with 'g', that appears before the whitespace" is too strict, as a sentence

    We broke the system with deployment-g42e13d8.

does want to link to 42e13d8, even though full-stop at the end is not whitespace, and the existing regexp uses \b there as a rough equivalent to saying "Here must be a whitespace or punctuation".

An attempt to tighten "what a punctuation is" by excluding '-' may make that "timestamp is in the tagname" example work, but is not a good solution, either, because two sentences can be concatenated with an em-dash that is often typed as two hyphen in plain text, resulting in something like

    We broke the system with deployment-g42e13d8--sigh.

and we do want to treat the '-' after 42e13d8 as a punctuation after
a described object name.
    
So I agree 3/3 is good thing to do as-is.

Thanks.