Jeff King <peff@xxxxxxxx> writes: > On Mon, Aug 08, 2011 at 11:08:26AM -0700, Junio C Hamano wrote: > > This seems related to the recent thread about showing branches only for > a specific remote: > > http://article.gmane.org/gmane.comp.version-control.git/178668 Yeah, that one I do recall. > Right now, "git branch -r" means "show everything under refs/remotes > instead of refs/heads". This would be easy to implement if it instead > meant "show all refs created by the RHS of a fetch refspec in a > configured remote". The two are equivalent in the default config, but > the latter may make more sense in a complex case. I actually am a bit ambivalent about this. I do not necessarily consider the contrived "remote.frotz.fetch = refs/heads/*:refs/remotes/nitfol/*" example something that we _must_ solve. It is unlikely people would do that, and if we give them an unexpected result, they deserve it ;-). But in real-life, it is entirely plausible that people with multiple integration branches are taking advantage of the simplicity of the old layout, i.e. [remote "origin"] fetch = refs/heads/master:refs/heads/origin fetch = refs/heads/next:refs/heads/next fetch = refs/heads/maint:refs/heads/maint fetch = +refs/heads/pu:refs/heads/pu I have many repositories of this style, and it is very convenient to be able to say: $ git checkout master && git pull --ff-only $ for b in master next maint pu do git checkout $b && make install || break done I do not think I want to ever switch them to new layout, and I suspect that many others do feel the same. Now, for these repositories, is "next" a local branch or a remote one? I have a feeling that it might be easier to understand if we label anything that you can update with "checkout && commit" a local one for the purpose of "branch -r" listing; IOW, the current "git branch -r" classification would match this use pattern better, even though refs/heads/next _is_ an RHS of a rule to follow others. In that sense, I would be entirely happy if the configuration variable used in this series were branch.<namepattern>.color and let you specify [branch "refs/heads"] color = yellow [branch "refs/remotes/origin"] color = purple [branch "refs/remotes/nitfol"] color = cyan It becomes complicated (and for no good reason, in my opinion; see the "next" example above) if you try to tie this with remote.<name> hierarchy, as it obviously becomes illogical not to use the "RHS of a fetch refspec" logic when we are talking about remote.<name>. -- 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