Jacob KellerOn Wed, Aug 12, 2015 at 9:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
> 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. >
Ok.
Show 7 quoted lines
> 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...}/*
>even if we maintained new git's abililty to work with this, ie: only external-to-git scripts would break and only for new clones? Maybe we don't want to go this route, but it seems like the way that the original proposal was headed.
Show 19 quoted lines
> - 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.
>I think this proposal makes the sense.. I'd go with something like:
refs/tracking/<origin>/(heads|tags|notes|replace|etc)/*
with a symlink from or into
refs/tracking/<origin>/heads -> refs/remotes/<origin>
I prefer tracking vs remote because "remote" and "remotes" are too similar for my taste. tracking I think gets the idea across pretty straight forward. Using a symlink personally I'd symlink the refs/tracking into refs/remotes rather than make refs/remotes the real storage.
Show 6 quoted lines
> 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.
I don't like it being so similar that we now have typos between remotes and remote.. ie: remotes/<origin> works for heads, but "remotes/<origin>/tags" does not... that sounds like it would get confusing.
Symlinking the old location seems reasonable to me, as it would leave all the same data in the locations expected by the old tools, while keeping all actual storage in the new location.
In this way, we would no longer need configuration settings. It honestly doesn't matter to me which direction we symlink either.
As for the other complex issue is what to do about "refs/tracking/<origin>/tags
The big discussion on the original thread is about how tags would work. I'm personally ok with *ignoring* tags and leaving it the way it is for now, and just doing this as a solid place to stick notes/replace/etc.
Or, we could go the route of continuing to stick tags into "refs/tags" at the same time as also sticking them into refs/tracking/<origin>/tags
Or.. we could go the full route of fixing up lookup of tags such that we put tags in refs/tracking/<origin>/tags and we have it lookup tags there via something like:
1) local tags preferred
2) any remote tag as long as all remote tags point to the same commit object (how we select which to use is not very relevant here... we could actually go with as long as the tag object is the same so two remotes with annotated tags pointing to the same object but different tag id would be ambiguous as well)
3) warn the user must disambiguate the tag via the remote name.
We could also teach fetch to warn about remote tags which are ambiguous (ie: two remotes with same named tag objects pointing to different things)
How goes this sound? I think it makes sense... I don't know how to do all this without breaking some backwards compatibility though... I think we can maintain expectations for the general user but I feel that any change here will break *someones* scripts.
Regards, Jake
