Re: Why doesn't gitk highlight commit references from git-describe?

From: Stefan Beller <sbeller@google.com>
Date: Apr 13, 2016, 21:45 UTC
Message-ID: <CAGZ79kY_C9wSS+z7XwPEWiM+8vhYuZzs_SPZ0mQR=LB+MPzTJg@mail.gmail.com>
In-Reply-To: <xmqqk2k1jita.fsf@gitster.mtv.corp.google.com>

On Wed, Apr 13, 2016 at 2:32 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

> Stefan Beller <sbeller@google.com> writes:
>
>> How would you know(/code) that v1.6.0-rc0~120^2 is a text worth linking?
>> "v1.6.0-rc0" is a custom string as that is how we name tags in this project.
>> It can follow any convention in other projects.
>>
>> Maybe a first approximation is if there is a `~` followed by numbers
>> or a ^ character, inspect the whole thing if it is a reference into the history?
>
> You (as a gitk process running in a repository) know what tags are
> in your repository, so you can find the above pattern and see if the
> prefix matches any of the known tag.  That way, you do not have to
> worry about having to special case HEAD etc.

Sorry for shooting from the hip here[1], that thought was

But it should not be just tags?

We also want to have 4b9ab0ee0130~1^2 to work `right`, in the sense that not just the hexadecimals are highlighted and linking to 4b9ab0ee0130, but the whole expression should link to 49e863b02ae177.

[1] My thinking was just like in https://xkcd.com/761/

Stephen Kelly:

> Would it be possible to implement linking for <tagname> optionally followed
> by something like that? Just tags should be links too, right?

right, just tags should work I'd expect.

> What does 'HEAD^' mean? If it is 'the commit before this one', then why not
> link it?

As said I was thinking about the git development, so see 5f3c3a4e6f11deda for an example:

    files_log_ref_write: new function

    Because HEAD and stash are per-worktree, every refs backend needs to
    go through the files backend to write these refs.

    So create a new function, files_log_ref_write, and add it to
    refs/refs-internal.h. Later, we will use this to handle reflog updates
    for per-worktree symbolic refs (HEAD).

I do not think we would want to link HEAD to anything in that example. (I'd have no idea what it would link to here, so just not link it?)

Thanks, Stefan