Re: [1.8.0] Remote tag namespace

On 11-02-01 05:44 AM, Nguyen Thai Ngoc Duy wrote:

On Tue, Feb 1, 2011 at 11:16 AM, Nicolas Pitre [off-list ref] wrote:

quoted

On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote:

quoted

Another random wish, which does not come with a proposal. How about
tag namespace (ie. tags from a remote stay in remote namespace)?

Please make this into a proper proposal.  this would be indeed a huge
improvement.

OK I'm not familiar with tag code, but I can try.

OK, that teaches me to read through _all_ the unread messages before posting!

Needless to say, I support this proposal.

Proposal:

Reserve refs/remote-tags namespace to store tags from remotes. Its
structure is the same as in refs/remotes. When pulling tags, put them
in refs/remote-tags/<remote> instead of refs/tags.
Tag dereference code will be taught about refs/remote-tags with
similar deref order as in remote branches.

I suggested a different home for the tags, but I don't have any insight into
what makes the most sense.  I'll defer to wiser folk on this.

Config branch.*.globalTags (perhaps takes a pattern?) may be defined
to create refs/tags/* in addition to refs/remote-tags/<remote>/* when
fetching tags.

I may be getting into the weeds prematurely here, but why put the config item
under branch.* ?  Or did you mean remote.*.globalTags?  Personally, I don't
see a need for this.  I'd rather have the rev-parse machinery search in
remote tag namespaces if it can't find anything local.

Migration plan:

refs/remote-tags will be used to store new tags unconditionally, which
means there will be duplicates with the already-fetched tags in global
namespace. Perhaps we can check if they point to the same sha-1, then
choose not to annoy users with ambiguous tag messages?

(Again with the weeds...)  I don't think we could do that.  I'd want to be
able to have my own (local) tags that refer to the same commits as one or
more remote tags, and I'd want to see them all.

Better for "git tag" to learn scoping options like "git branch": -a and -r.
(Hmm, maybe git-tag's current -a could become -A...)

I suggest to add config compatibility.remoteTagNamespace, default to
false, which retains current behavior (i.e. also create tags in global
namespace in addition to refs/remote-tags). After 1.8.0 (or a few more
cycles) the default value becomes true. Users who wish to keep old
behavior can put "false" in their ~/.gitconfig.

After a few years, remove support for the config key. Unrecognized
compatibility.* keys will abort program. Users are forced to new
behavior. I don't know, we may want to start annoy users that have the
config key set a few cycles before we drop support.

Sounds good.  I'd vote for a faster transition, but that's just me.  :)

		M.