Re: [PATCH] Support specific color for a specific remote branches

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 8, 2011, 21:31 UTC
Message-ID: <7v62m7wpxg.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110808205214.GG18294@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

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

Show 5 quoted lines

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