[1.8.0] Remote tag namespace
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Feb 1, 2011, 10:44 UTC
- Message-ID
- <AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com>
On Tue, Feb 1, 2011 at 11:16 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
Show 6 quoted lines
> On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote: >> 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.
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.
Config branch.*.globalTags (perhaps takes a pattern?) may be defined to create refs/tags/* in addition to refs/remote-tags/<remote>/* when fetching tags.
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?
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.
-- Duy