Jeff King [off-list ref] 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>.
On Mon, Aug 08, 2011 at 02:31:39PM -0700, Junio C Hamano wrote:
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
[...]
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.
Agreed, that really muddies the idea of what is a "remote branch" and
what is not. I think there is a sense among users that "local branches"
and "remote branches" are mutually exclusive sets, even though by some
definitions they may not be (i.e., if you define the former by where in
the refs/ hierarchy they exist, and the latter by being the RHS of a
remote fetch refspec).
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
There are two issues I see with that:
1. Until now, "branch" sections like this have always been about local
branches. What are the rules for defining something like
"branch.refs/remotes/origin/foo.merge"? Knowing how the code works,
it is easy to say it is a noop, as we will never look at it. But I
wonder how it looks from the perspective if a recent git user.
2. Until now, "branch" sections specify full refs, not subsets or
wildcard patterns. What does "branch.refs/heads.merge" mean?
A noop? A wildcard with slightly lesser precedence than
"branch.refs/heads/foo.merge"?
If we are going to go this route, I think it is really about introducing
properties not on branches, but on subsets of the ref namespace. So
might say:
[ref "refs/heads/*"] color = yellow
which says "whenever you are dealing with this part of the refs
namespace, my preferred color is yellow". And "git branch" happens to
respect that (and we could just as easily have a "%(refcolor)" marker in
git-for-each-ref).
I know the difference is subtle, but I just think it removes entirely
the question about what is a branch and what is not. Furthermore, it
naturally extends to other commands (e.g., you could color subsets of
the tag namespace differently), to more complex layouts (e.g., if we
end up moving fetched tags into the refs/remotes namespace eventually),
and to other properties besides color (though I haven't though up any
applications).
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>.
We've been discussing the coloring issue here. But the other thread I
pointed out was about asking "which fetched branches do we have locally
for this remote?". Which is a very reasonable thing to ask, and which
don't do a good job of answering right now. And I think it has to
do the "RHS of a fetch refspec thing".
Right now you can do "git remote show". But:
1. It's very heavyweight. It shows you way more than you want in most
cases, and it touches the network by default (there is a "-n"
option, but touching the network by default makes it pretty
un-git).
2. It's not as easily discoverable as "git branch -r". It's not
unreasonable for users to mentally go through the sequence:
a. "git branch" shows me branches
b. oh, it has an "-r" option for remotes
c. how do I limit to one remote?
I'm not sure what the right solution is. Going from 2b to 2c is a very
natural thing for a user to want to do. But it means jumping from one
definition of "remote" (i.e., everything under "refs/remotes") to
another (the config defined by remote "foo"). In the default config,
that is a natural jump, as they are semantically connected. But they
don't have to be.
-Peff