Jacob Keller <jacob.keller@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html