Re: Tag refspecs (was Re: [PATCH] Remove restriction on notes ref base)

[Marc Branchaud <marcnarc@xiplink.com>]

On 10-11-04 09:02 PM, Johan Herland wrote:
> On Thursday 04 November 2010, Marc Branchaud wrote:
>> On 10-11-03 08:49 PM, Johan Herland wrote:
>>> I'd probably suggest a more straightforward (and hopefully less
>>> confusing)
>>>
>>> setup like this:
>>>   Remote repo    ->   Local repo
>>>   ------------------------------------------------
>>>   refs/heads/*        refs/remotes/$remote/heads/*
>>>   refs/tags/*         refs/remotes/$remote/tags/*
>>>   refs/notes/*        refs/remotes/$remote/notes/*
>>>
>>> ...and these would all be set in the config, i.e. no implicit/magic
>>> refspecs.
>>
>> I'll second this proposal, at least as far as tags go.  I can offer two
>> reasons to support this.
>>
>>
>> First, I think the assumption that tags are immutable is too strong.  In
>> our repo, we try to keep our topic branches mergeable into both the
>> "master" and "maintenance-of-the-latest-release" branches.
>>
>> This means the topic branches need to be based at the point where the
>> maintenance and master branches diverged.  Making this rule easy to
>> follow is best accomplished with a tag, e.g. "topic-base", but that tag
>> will move when we create a new maintenance branch for a new release. 
>> With the current tag semantics, when that happens everyone has to delete
>> their local topic-base tags and get the new one from the common/shared
>> repo.  People who forget to do this end up basing their topics on
>> outdated code, with predictable results.
>>
>> It would be much easier to be able to just use an "origin/topic-base" tag
>> instead, one that that tracks the topic-base tag in the origin repo.
> 
> Actually, this is not a valid reason. To me, it sounds like your "topic-
> base" tag _really_ should be a "topic_base" _branch_. The branch is 
> initialized to the merge-base between "master" and "maintenance-of-the-
> latest-release" branches, and when you create a new maintenance branch, the 
> "topic-base" branch is fast-forwarded along the master branch until it 
> reaches the merge-base with the new maintenance branch. (Remember that 
> branches really are nothing but named pointers into the commit graph, and as 
> long as the "topic-base" branch stays within the history of the "master" 
> branch, it does not constitute a proper "branch", i.e. a fork in the commit 
> history.)

I understand how a branch can, with careful management, mechanically achieve
the behaviour I want.

But the problem with that approach is that it breaks as soon as someone
commits to the topic-base branch (an easy mistake to make, especially for
rookie users).  Then that person would base later topics on the wrong commit,
and worse, if they pushed their "topic-base" branch to our shared repo then
everyone would be affected.

A hook in the shared repo could prevent the pushing of the topic-base branch,
but that that's just a complicated, half-baked way of making a branch behave
like a tag.  A tag doesn't need the careful management that a branch would.


Anyway, regardless of whether or not the scenario I described is valid, I
still wonder if tag immutability makes sense when remote tags live in the
repo's namespace.  If a repo first sets tag "foo" to point to commit 'A' then
later changes "foo" to point to 'B', shouldn't my clone's "repo/foo" tag
update automatically to reflect that?  I see little point in keeping my
"repo/foo" tag pointing at commit 'A'.

		M.