Thread (30 messages) flat view 30 messages, 4 authors, 2016-06-15

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

From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:57:19

Duy Nguyen wrote:
Hmm.. I missed that mail (or I wouldn't have worked on this already).
Do you want to take over?
Oh, we can collaborate on one beautiful series :)
"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.
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?
quoted
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?
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).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help