[RFC] Porting builtin/branch.c to use the printing options of ref-filter.{c,h}

[RFC] Porting builtin/branch.c to use the printing options of ref-filter.{c,h}

[Karthik Nayak]

I'm working on porting over the printing options of ref-filter to `git
branch -l`.
This is a follow up to
http://article.gmane.org/gmane.comp.version-control.git/276377

Theres a slight issue with this which I'd like to discuss about.

When we use `-a` option in `git branch -l`
It lists local branches and remotes with each having a different output format.
This with reference to ref-filter would mean either

1. Change format in between local and remote refs
2. Have a format like %(if)...local check....%(then)....local branch
format....%(else)....remote format %(end).

I prefer the latter, but that might lead to a large format. Any suggestions?


-- 
Regards,
Karthik Nayak

Re: [RFC] Porting builtin/branch.c to use the printing options of ref-filter.{c,h}

[Junio C Hamano]

Karthik Nayak <karthik.188@gmail.com> writes:

> I'm working on porting over the printing options of ref-filter to `git
> branch -l`.
> This is a follow up to
> http://article.gmane.org/gmane.comp.version-control.git/276377
>
> Theres a slight issue with this which I'd like to discuss about.
>
> When we use `-a` option in `git branch -l`
> It lists local branches and remotes with each having a different output format.
> This with reference to ref-filter would mean either
>
> 1. Change format in between local and remote refs

I thought the end result of consolidation would be for for-each-ref,
branch -l, and tag -l to be "first collect what to show, and then
show them according to a single format given".  How could it be
possible to switch format?  It's not even like each element collected
in the first phase is marked so that the second "display" phase know
which one is which.

> 2. Have a format like %(if)...local check....%(then)....local branch
> format....%(else)....remote format %(end).

That, if we had a working if/then/else/end, would be a good
demonstration of it.  

If this were only for internal use by "branch -l", it might be
overkill, but the end users with for-each-ref --format options would
want to do the same thing as built-in patterns, so it is a good goal
to aim at.

> I prefer the latter, but that might lead to a large format. Any suggestions?

A less ambitious option might be:

  3. Invent "%(refname:<some magic>)" format similar to
     %(refname:short) but does your thing depending on the prefix
     refs/heads/ and refs/remotes/.

but that will not work if the difference between local and remote
format is not merely textual (e.g. paint them in different color).

Re: [RFC] Porting builtin/branch.c to use the printing options of ref-filter.{c,h}

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> A less ambitious option might be:
>
>   3. Invent "%(refname:<some magic>)" format similar to
>      %(refname:short) but does your thing depending on the prefix
>      refs/heads/ and refs/remotes/.

Actually, this is the option I suggest offline.

> but that will not work if the difference between local and remote
> format is not merely textual (e.g. paint them in different color).

Hmm, yes, colors would be difficult to get with this solution. Perhaps a
%(refname:autoprefix,autocolor) that would pick the color and do the
textual rendering?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC] Porting builtin/branch.c to use the printing options of ref-filter.{c,h}

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Hmm, yes, colors would be difficult to get with this solution. Perhaps a
> %(refname:autoprefix,autocolor) that would pick the color and do the
> textual rendering?

Yeah, that's workable.

Re: [RFC] Porting builtin/branch.c to use the printing options of ref-filter.{c,h}

[Karthik Nayak]

On Wed, Aug 26, 2015 at 12:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> I'm working on porting over the printing options of ref-filter to `git
>> branch -l`.
>> This is a follow up to
>> http://article.gmane.org/gmane.comp.version-control.git/276377
>>
>> Theres a slight issue with this which I'd like to discuss about.
>>
>> When we use `-a` option in `git branch -l`
>> It lists local branches and remotes with each having a different output format.
>> This with reference to ref-filter would mean either
>>
>> 1. Change format in between local and remote refs
>
> I thought the end result of consolidation would be for for-each-ref,
> branch -l, and tag -l to be "first collect what to show, and then
> show them according to a single format given".  How could it be
> possible to switch format?  It's not even like each element collected
> in the first phase is marked so that the second "display" phase know
> which one is which.
>

Absolutely right! Currently this is not even possible, It was just a shot in the
dark. I was just shooting out possibilities I could think of :)

>> 2. Have a format like %(if)...local check....%(then)....local branch
>> format....%(else)....remote format %(end).
>
> That, if we had a working if/then/else/end, would be a good
> demonstration of it.
>
> If this were only for internal use by "branch -l", it might be
> overkill, but the end users with for-each-ref --format options would
> want to do the same thing as built-in patterns, so it is a good goal
> to aim at.
>

I have a version of that running in my local repo, I'll probably
post a WIP soon, when I get this done.

>> I prefer the latter, but that might lead to a large format. Any suggestions?
>
> A less ambitious option might be:
>
>   3. Invent "%(refname:<some magic>)" format similar to
>      %(refname:short) but does your thing depending on the prefix
>      refs/heads/ and refs/remotes/.
>
> but that will not work if the difference between local and remote
> format is not merely textual (e.g. paint them in different color).

It's more than just colors. The whole format changes.

$ git branch -a
For local:
"%(if)%(HEAD)%(then)%(HEAD) %(color:green)%(refname:short)%(else)
%(refname:short)%(end)"
For remote:
"  remotes/%(color:red)%(refname:short)%(color:reset)%(if)%(symref)%(then)
-> %(symref:short)%(end)"



On Wed, Aug 26, 2015 at 1:36 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
>
> Hmm, yes, colors would be difficult to get with this solution. Perhaps a
> %(refname:autoprefix,autocolor) that would pick the color and do the
> textual rendering?
>

That sounds, good, probably could work on something of this sort.

-- 
Regards,
Karthik Nayak

Re: [RFC] Porting builtin/branch.c to use the printing options of ref-filter.{c,h}

[Matthieu Moy]

Karthik Nayak <karthik.188@gmail.com> writes:

> It's more than just colors. The whole format changes.
>
> $ git branch -a
> For local:
> "%(if)%(HEAD)%(then)%(HEAD) %(color:green)%(refname:short)%(else)
> %(refname:short)%(end)"
> For remote:
> "  remotes/%(color:red)%(refname:short)%(color:reset)%(if)%(symref)%(then)
> -> %(symref:short)%(end)"

I think both versions are not so different. You have %(if) on one format
strings that would be disabled by construction on the second. For
example, adding %(if)%(HEAD)%(then)%(HEAD) at the start of the
format-string for remotes would be a no-op, right?

And in case a local branch is a symref, "git branch" displays "-> ..."
both for local and for remotes. You just normally don't have local
symref branches other than HEAD, but I tried:

$ git checkout -b branch
$ cat .git/HEAD > .git/refs/heads/symref
$ git branch -a
* branch
  master
  symref -> branch

The only remaining difference I see are the "remotes/" prefix and
colors.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/