Re: proper remote ref namespaces

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 12, 2015, 16:10 UTC
Message-ID: <xmqqfv3omqsh.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CA+P7+xpj+8DZ=K0pna299Mu3nsQ4+JV_JUK=WFzzAFnJN+Bkbg@mail.gmail.com>

Jacob Keller <jacob.keller@gmail.com> writes:

> Recently there was some discussion about git-notes and how we do not
> fetch notes from remotes by default. The big problem with doing so is
> because refs/remotes/* hierarchy is only setup for branches (heads),
> so we don't have any clean location to put them.

I wouldn't call this topic "proper" namespaces, though. What we have is widely used and it shouldn't be broken. Call it "enhanced", perhaps.

Some design boundaries:

 - Moving the remote-tracking branch hierarchy from refs/remotes/$O/*
   to refs/remotes/$O/heads/* would not fly, because it will break
   existing repositories.  Do not even waste time on pursuing
   refs/remotes/$O/{heads,tags,notes...}/*

 - Extending the current refs/remotes/$O/* (for branches) and doing
   refs/remote-tags/$O/* (for tags) may work, would not break
   existing repositories, and could to be extended further to cover
   refs/remote-notes/$O and friends.  It however may not look pretty
   (weak objection) and more importantly, it would make it harder to
   "cull" things that came from a single remote.

Just thinking aloud, perhaps we can introduce a brand new top level hierarchy refs/remote/$O/{heads,tags,notes,...}, and give backward compatibility by making a moral equivalent of a symbolic link from refs/remote/$O/heads to refs/remotes/$O/. The true remote-tracknig refs continue to live in refs/remotes/$O/* and old tools that do not know the new layout would not be hurt. New tools that want to ignore and look only at refs/remote/$O/* can do so through the moral equivalent of a symbolic link. "remote remove" needs to be taught about this single exception (i.e. "the symbolic link"), but the places it needs to touch is limited only to two places and will not grow.

If somebody got confused, notice that in the above description, I said refs/remotes/ and refs/remote/. The former must stay. The name of the latter is open to bikeshedding. Some may prefer a name that is more distinct (refs/tracking/ or something, perhaps?). I happen to prefer a name that is similar, but this preference is very weak and I can persuaded to go either way.