Headless tags don't have a follows or precedes?

I've noticed that if I create a headless tag (one that doesn't have a branch, right?),

when I click on that commit, it doesn't have precedes or follows information. Is this by design?

I have never heard tag being described as headless... A tag is just a pointer on some commit (annotated tag contains additional information such as creater, data, message), in any case, it has no direct relation to any branch.

Tags do not store any precedes or follows information, no matter how you created them, but visualization tools can look at the tree and display what was before some commit and what was after it. Without seeing your tree, it is impossible to tell whether gitk (or what you use?) displayed that correctly or not.

Hi all,

I've noticed that if I create a headless tag (one that doesn't have a branch, right?), when I click on that commit, it doesn't have precedes or follows information. Is this by design? Is there a work-around I can use without creating a branch there?

Tim Mazid venit, vidit, dixit 01.11.2009 10:31:

Quoted 3 lines

Hi all,

Quoted 4 lines

I've noticed that if I create a headless tag (one that doesn't have a branch, right?), when I click on that commit, it doesn't have precedes or follows information. Is this by design? Is there a work-around I can use without creating a branch there?

Reposting (without even saying so) doesn't necessarily increase your chance of getting responses.

Would would help:

- saying you're talking about gitk/git view/whatever it is you're "clicking" on

- providing a minimal example others can reproduce. That would be one where a tag on a detached head (assuming that's what you mean) has no precedes/follow but a tag "on a branch" does have that info

Quoted 10 lines · Michael J Gruber-2 wrote:

Tim Mazid venit, vidit, dixit 01.11.2009 10:31:

Quoted 7 lines

Hi all,

I've noticed that if I create a headless tag (one that doesn't have a branch, right?), when I click on that commit, it doesn't have precedes or follows information. Is this by design? Is there a work-around I can use without creating a branch there?

Quoted 3 lines

Reposting (without even saying so) doesn't necessarily increase your chance of getting responses.

I didn't repost. Or at the least, I didn't mean to repost. The mailing list kept complaining (spamming me) that my post was pending, and I eventually realised that was the old forum. I deleted it from there, and copy-pasted here. I didn't even realise it had posted here, and that when I deleted from the old forum, it didn't delete here.

Quoted 6 lines · Michael J Gruber-2 wrote:

Would would help:

- saying you're talking about gitk/git view/whatever it is you're "clicking" on

My apologies, yes, in gitk.

Quoted 5 lines · Michael J Gruber-2 wrote:

- providing a minimal example others can reproduce. That would be one where a tag on a detached head (assuming that's what you mean) has no precedes/follow but a tag "on a branch" does have that info

Example (unless specified, commands as entered into bash)

mkdir temp
cd temp
git init
gitk --all &
git commit --allow-empty -m '1'
git tag v1
git commit --allow-empty -m '1.1'
git tag v1.1
git commit --allow-empty -m '1.2'
git tag v1.2
(in gitk, press ctrl+f5; all follows and precedes info is there) git checkout v1.1
git commit --allow-empty -m '1.1.1'
git tag v1.1.1
(in gitk, press f5; follows and precedes info missing for v1.1 and v1.1.1)

(close gitk)
gitk --all &
(info still missing)
git commit --allow-empty -m '1.1.2'
git tag v1.1.2
(in gitk, press f5, info still missing)

git checkout master
git commit --allow-empty -m '1.3'
git tag v1.3
(in gitk, press f5, info still missing)

git commit --allow-empty -m '1.4'
git tag v1.4
(in gitk, press f5, info still missing)
git checkout -b temp v1.2
git commit --allow-empty -m '1.2.1'
git tag v1.2.1
(in gitk, press f5, info still missing)
git checkout master
git branch -D temp
git commit --allow-empty -m '1.5'
git tag v1.5
(in gitk, press f5, info still missing)

In the end, the only follows/precedes info is:
v1: precedes v1.1
v1.1: follows v1, precedes v1.2
v1.2: follows v1.1
All the rest is missing.

Tim Mazid venit, vidit, dixit 02.11.2009 14:07:

Quoted 9 lines

Quoted 6 lines · Michael J Gruber-2 wrote:

Would would help:

- saying you're talking about gitk/git view/whatever it is you're "clicking" on

My apologies, yes, in gitk.

Now we only need the version... but we'll see if current versions reproduce it.

Quoted 8 lines

Quoted 5 lines · Michael J Gruber-2 wrote:

- providing a minimal example others can reproduce. That would be one where a tag on a detached head (assuming that's what you mean) has no precedes/follow but a tag "on a branch" does have that info

Example (unless specified, commands as entered into bash)

Great example, thanks!

Quoted 17 lines

mkdir temp
cd temp
git init
gitk --all &
git commit --allow-empty -m '1'
git tag v1
git commit --allow-empty -m '1.1'
git tag v1.1
git commit --allow-empty -m '1.2'
git tag v1.2
(in gitk, press ctrl+f5; all follows and precedes info is there) git checkout v1.1
git commit --allow-empty -m '1.1.1'
git tag v1.1.1
(in gitk, press f5; follows and precedes info missing for v1.1 and v1.1.1)

For me, v1.1.1 has no info and v1.1 is missing v1.1.1 in its precedes.

Quoted 6 lines

(close gitk)
gitk --all &
(info still missing)
git commit --allow-empty -m '1.1.2'
git tag v1.1.2
(in gitk, press f5, info still missing)

v1.1.1 and v1.1.2 missing all follow/precede info.

Quoted 4 lines

git checkout master
git commit --allow-empty -m '1.3'
git tag v1.3
(in gitk, press f5, info still missing)

Now, even v1.3 is missing its follows and v1.2 its precedes, even though they've got nothing to do with the "detached branch".

Quoted 14 lines

git commit --allow-empty -m '1.4'
git tag v1.4
(in gitk, press f5, info still missing)
git checkout -b temp v1.2
git commit --allow-empty -m '1.2.1'
git tag v1.2.1
(in gitk, press f5, info still missing)
git checkout master
git branch -D temp
git commit --allow-empty -m '1.5'
git tag v1.5
(in gitk, press f5, info still missing)

Quoted 5 lines

In the end, the only follows/precedes info is:
v1: precedes v1.1
v1.1: follows v1, precedes v1.2
v1.2: follows v1.1
All the rest is missing.

So basically, all connectivity which has been created after detaching the head is missing, even that which has been created on a "proper branch", which means (to me) it has nothing to do with git's revision parsing (such as missing out on lightweight tags on detached heads).

I looked at the gitk code and got the expected result: no clue (tcl/tk doesn't tick my fancy). gitk's parsing of ancestry relations seems to be done completely in tcl (rather then relaying a lot to git-rev-parse, which may not be efficient here). So I'll take the liberty to cc the main gitk guy. A few more notes:

After generating v1.1.1 (which misses "follows"), .git/gitk.cache has this (\n added for clarity):

1 1\n
6bfcf857ceef0507bb50ee17302c1d068b697540
b67f4651e49a33ee8cc77157e4e51d1e635a7c0d
{540abf2b75aec7ccbd8c0413863a018fc1c1eb37
b67f4651e49a33ee8cc77157e4e51d1e635a7c0d}\n
1\n

If I move that out of the way and rerun gitk, everything's in apple pie order, and the cache file is:

1 3\n
2fd83b12ccea07c88f5998aa6303003ef1e4858b
540abf2b75aec7ccbd8c0413863a018fc1c1eb37
540abf2b75aec7ccbd8c0413863a018fc1c1eb37\n
6bfcf857ceef0507bb50ee17302c1d068b697540
540abf2b75aec7ccbd8c0413863a018fc1c1eb37
540abf2b75aec7ccbd8c0413863a018fc1c1eb37\n
540abf2b75aec7ccbd8c0413863a018fc1c1eb37
b67f4651e49a33ee8cc77157e4e51d1e635a7c0d
b67f4651e49a33ee8cc77157e4e51d1e635a7c0d\n
1\n

Unsurprisingly, v1.1.2 (committed & tagged on a detached head) trips things up again, moving gitk.cache out of the way helps again.

Surprisingly, v1.3 (committed and tagged on a checked out branch) trips things up again, moving... helps again.

Paul, I hope you can make sense of this. Something in gitk.cache prevents gitk from rescanning for new children, an empty cache gets it right, but only until the next run.

Michael