Re: [PATCH/WIP 0/9] for-each-ref format improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, May 19, 2013 at 7:08 PM, Ramkumar Ramachandra
<artagnon@xxxxxxxxx> wrote:
>> "branch -vv" shows [upstream: ahead x, behind y]. We need a syntax to
>> cover that too.
>
> Can't we construct that using [%(upstream:short): %(upstream:diff)]?
> It's nothing fundamental.

If there is no upstream, [] should not be shown. We don't have
conditional specifiers so [] should be produced by one of the
specifiers. But yes it's nothing fundamental.

>> pretty and for-each-ref format seem to be on the opposite: one is
>> terse, one verbose. Unless you are going to introduce a lot of new
>> specifiers (and in the worst case, bring all pretty specifiers over,
>> unify underlying code), I think we should stick with %(xx) convention.
>
> We can stick to using the existing %(...) atoms: there's no need to go
> as far as %an versus %aN.  The atoms cannot be consistent with
> pretty-formats anyway, because pretty-formats has completely different
> atoms.  For the _new_ stuff like color and alignment, we can be
> consistent with pretty-formats, no?

I don't think you can easily borrow parsing code from pretty-formats
(but I may be wrong). Anyway new stuff with new syntax would look
alien in for-each-ref format lines. Either we bring --pretty to
for-each-ref, leaving all for-each-ref atoms behind in --format, or we
should follow %(..) convention if we add new stuff to --format.

>
>>> Why should we deviate from the pretty case?  What is different here?
>>
>> Laziness plays a big factor :) So again, you want to take over? ;)
>
> It's just a matter of modifying the parsing/printing layer, instead of
> introducing new atoms in the current parser.  Doesn't $gmane/224692
> demonstrate that the former can, in fact, be easier?

Yes it looks so.

>
>> it uses builtin/branch.c:branch_use_color. Eventually
>> fill_tracking_info() should be moved to for-each-ref.c and pass
>> branch_use_color in as an argument. But for now, I just leave it
>> broken.
>
> Auto-color can come later: it's not that urgent.  What's more
> important is that we give users the flexibility to set their own
> colors now.
>
> Can you give me a pull URL to your series, so we can start
> collaborating?  Mine's at gh:artagnon/git (branch: hot-branch).

https://github.com/pclouds/git/tree/for-each-ref-pretty

I merged 07/09 and 08/09 together as they should be one.
--
Duy
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]