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