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

[Tim Mazid <timmazid@hotmail.com>]

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.