Re: [PATCH/WIP 0/9] for-each-ref format improvements
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- May 19, 2013, 12:28 UTC
- Message-ID
- <CACsJy8DhdR-jWQmL1aYSnH=6w9RKGp0_pRnAzvZEPbJ7MSdMtA@mail.gmail.com>
- In-Reply-To
- <CALkWK0kYDB+cCsD7Fsymf9ETR2Ymyaf072gCUu6Uh8yFVFJV2Q@mail.gmail.com>
On Sun, May 19, 2013 at 7:08 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
Show 5 quoted lines
>> "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.
Show 10 quoted lines
>> 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.
Show 8 quoted lines
> >>> 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.
Show 12 quoted lines
> >> 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