# Headless tags don't have a follows or precedes?

5 messages from 2009-11-01 to 2009-11-20. Participants: Tim Mazid, Michael J Gruber.
Thread: https://gitlist.dev/t/21449

## Tim Mazid, 2009-11-01 09:31

Subject: Headless tags don't have a follows or precedes?
Message-ID: <1257067898626-3926483.post@n2.nabble.com>
URL: https://gitlist.dev/e/1257067898626-3926483.post%40n2.nabble.com

```

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?

Thanks,
Tim.
-- 
View this message in context: http://n2.nabble.com/Headless-tags-don-t-have-a-follows-or-precedes-tp3926483p3926483.html
Sent from the git mailing list archive at Nabble.com.

```

## Michael J Gruber, 2009-11-02 09:42

Subject: Re: Headless tags don't have a follows or precedes?
Message-ID: <4AEEA96F.7080609@drmicha.warpmail.net>
URL: https://gitlist.dev/e/4AEEA96F.7080609%40drmicha.warpmail.net
In-Reply-To: <1257067898626-3926483.post@n2.nabble.com>

```
Tim Mazid venit, vidit, dixit 01.11.2009 10:31:
> 
> 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?

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

Cheers,
Michael

```

## Tim Mazid, 2009-11-02 13:07

Subject: Re: Headless tags don't have a follows or precedes?
Message-ID: <1257167247221-3931674.post@n2.nabble.com>
URL: https://gitlist.dev/e/1257167247221-3931674.post%40n2.nabble.com
In-Reply-To: <4AEEA96F.7080609@drmicha.warpmail.net>

```


Michael J Gruber-2 wrote:
> 
> Tim Mazid venit, vidit, dixit 01.11.2009 10:31:
>> 
>> 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?
> 
> 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.


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.


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.
-- 
View this message in context: http://n2.nabble.com/Headless-tags-don-t-have-a-follows-or-precedes-tp3926483p3931674.html
Sent from the git mailing list archive at Nabble.com.

```

## Michael J Gruber, 2009-11-02 15:54

Subject: Re: Headless tags don't have a follows or precedes?
Message-ID: <4AEF009E.5060005@drmicha.warpmail.net>
URL: https://gitlist.dev/e/4AEF009E.5060005%40drmicha.warpmail.net
In-Reply-To: <1257167247221-3931674.post@n2.nabble.com>

```
Tim Mazid venit, vidit, dixit 02.11.2009 14:07:
> 
> 
> Michael J Gruber-2 wrote:
>>
>> Tim Mazid venit, vidit, dixit 01.11.2009 10:31:
>>>
>>> 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?
>>
>> 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.
> 

OK :) (It git through to gmane a while ago.)

> 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.

> 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!

> 
> 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.

> (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.

> 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".

> 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.

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

```

## Tim Mazid, 2009-11-20 01:07

Subject: Re: Headless tags don't have a follows or precedes?
Message-ID: <1258679266168-4035472.post@n2.nabble.com>
URL: https://gitlist.dev/e/1258679266168-4035472.post%40n2.nabble.com
In-Reply-To: <4AEF009E.5060005@drmicha.warpmail.net>

```

Hey list,

I was just wondering if there were any updates to this?

Also, I believe I forgot to mention the gitk version, it's 1.6.5.3-1.

Cheers,
Tim.


Michael J Gruber-2 wrote:
> 
> Tim Mazid venit, vidit, dixit 02.11.2009 14:07:
>> 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.
> 
>> 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!
> 
>> 
>> 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.
> 
>> (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.
> 
>> 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".
> 
>> 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.
> 
> 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
> 

-- 
View this message in context: http://n2.nabble.com/Headless-tags-don-t-have-a-follows-or-precedes-tp3926483p4035472.html
Sent from the git mailing list archive at Nabble.com.

```