Stefan Beller [off-list ref] 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.
On Wed, Apr 13, 2016 at 2:32 PM, Junio C Hamano [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
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
Stefan Beller wrote:
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.
Presumably the same logic which finds 4b9ab0ee0130 to link it can also see
if it is suffixed with '~1^2' ?
Is a ref like 4b9ab0ee0130~1^2 commonly useful? In cmake we use the output
of cmake describe --contains (when there is a following tag) to refer to
commits, in a pattern which I've also seen in git.git occasionally:
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23f3798c
I think the only reason for using the output of cmake describe --contains is
that it shows the reader the 'era' of the commit (and release it appears in)
without having to look it up. I'm not really aware of another good reason to
use it, but I think that's enough to make sense.
However I'm not sure I understand why anyone would refer to 4b9ab0ee0130~1^2
instead of 49e863b0 (or perhaps v2.6.5~12, depending on whether the tag is
there).
quoted
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
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?)
Right, so if a commit message contains something like
Make git rebase -i HEAD^^^^ ten times better
then HEAD^^^^ shouldn't become a link. Makes sense to me.
Thanks,
Steve.