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
--
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