Re: Cogito: cg-clone doesn't like packed tag objects

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Sep 27, 2005, 13:27 UTC
Message-ID: <200509271527.26050.Josef.Weidendorfer@gmx.de>
In-Reply-To: <20050927123455.GE30889@pasky.or.cz>

On Tuesday 27 September 2005 14:34, Petr Baudis wrote:

Show 5 quoted lines

> But we don't need any global tags or heads. You just have some heads in
> your refs/heads (it doesn't matter if they are public or remote, that's
> a "social" issue what you tell people to fetch). And based on your heads
> you have in your refs/heads, there would be directories in your
> refs/tags/ corresponding to those.

Ah, ok.

Let me see if I understand:
1) These tags are bound to a head, and they have the invariant that they 
appear in the commit history of the head.
2) They are updated automatically.
3) When someone rebases a head, the bound tags should be synced to the
rebased head's history.
4) Tags can appear multiple times, if they happen to be in the commit
history of multiple heads?

How to make sure that the invariant mentioned in (1) always holds?

> If you fetch remote head, its local subdirectory in refs/tags/ is
> populated with the new tags, and if you merge two heads, the public tags
> are copied around.

Ok, this is the "automatically updated" feature I talked about above.
So missing here is:
- If you want to get rid of a head, the tags should be removed
- If a head is rebased, this has to be detected and the tags recreated,
possibly removing some

Probably there should be a "cg-tag --recover" to resync these volatile tags with tag objects appearing in the histories of heads?

As for lightweight tags of remote repositories, you probably need some space to recover them e.g. on a rebase or creation of a new head without running git-ls-remote all the time.

> Then if you are resolving a tag, we should first look 
> at refs/tags/$(readlink HEAD)/tagname, and if it doesn't exist, we would
> look at refs/tags/tagname (so if you wanted to reference a tag not in
> your head, you'd have to use a "head/tag" form).

Sounds nice.

> > Perhaps interpret tag objects as global branch names, similar to
> > the "mixture" in .git/refs ?
>
> I don't understand.

Tag objects in a repository could be interpreted as branch names for commits based on it. When creating a new branch point, I first would put a tag object on this branch, thus renaming it. I think this would be quite handy for navigation in histories.

Josef