Headless tags don't have a follows or precedes?

Headless tags don't have a follows or precedes?

[Tim Mazid]

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://www.nabble.com/Headless-tags-don%27t-have-a-follows-or-precedes--tp26093136p26093136.html
Sent from the git mailing list archive at Nabble.com.

Re: Headless tags don't have a follows or precedes?

[Dmitry Potapov]

On Wed, Oct 28, 2009 at 04:36:59AM -0700, Tim Mazid wrote:
> 
> I've noticed that if I create a headless tag (one that doesn't have a
> branch, right?),

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.

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

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.


Dmitry

Re: Headless tags don't have a follows or precedes?

[Tim Mazid]

Dmitry Potapov wrote:
> 
> 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.
> 
Well, not the tag itself, but the commit the tags points to. Same thing.
Like you're always bothered to say "the commit that the tag v1 points to"
rather than "the v1 tag".
Also, see my post above.
-- 
View this message in context: http://n2.nabble.com/Headless-tags-don-t-have-a-follows-or-precedes-tp3926483p3931717.html
Sent from the git mailing list archive at Nabble.com.

Headless tags don't have a follows or precedes?

[Tim Mazid]

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.

Re: Headless tags don't have a follows or precedes?

[Michael J Gruber]

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

Re: Headless tags don't have a follows or precedes?

[Tim Mazid]

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.

Re: Headless tags don't have a follows or precedes?

[Michael J Gruber]

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

Re: Headless tags don't have a follows or precedes?

[Tim Mazid]

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.