Johan Herland <jo...@herland.net> writes: > Ok, so whereas I consider the refspec to be "king", and that the expansion > from convenient shorthands to full remote-tracking refnames should be > derived from the chosen refspec, you would (if I understand you correctly) > rather have a constant (i.e. independent of remotes and refspecs) set of > rules for expanding shorthands to full refnames, and if the user chooses > refspecs that don't mesh well with those rules, then that is the user's > problem, and not Git's.
You need to dig your rhetoric from the other end of the tunnel. I would consider the local namespace for the refs to be the "king", and we would design how they are resolved to be useful for user's local usage pattern. How the remote refs are copied by fetch following refspecs is one of the many components (e.g. the dwimming machinery "checkout foo" uses to guess that the user may want to fork from and integrate later with one of the refs under refs/remotes is one of them and it is not "fetch") to complement the refname resolution rule to support the local usage of refs. > In light of this, I'm interested in your thoughts about the following > related problem that I've just started looking at: > > git branch -r shows the remote-tracking branches in this repo. Currently, > .... Should we add a heuristic for detecting when > to use refs/remotes/* vs. refs/remotes/*/heads/* as a filter? Didn't I already said that I do not think repurposing refs/remotes/ for these "unified" copies is the best approach? A change that I think is a good thing to add on top of your [45]/7 refactoring is to allow the user to add custom expansion/contraction rules. Then the user can group refs regardless of "remotes" and give meaningful shortening. As I said in a very early review, viewing "fetch refspec" to be "king" and refspecs are the only way the user may want to group things locally is myopic. The every-day usage of the local names ought to be the king, and everything else should serve to make it easier to use. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
