On Tue, Jun 4, 2013 at 7:52 PM, Ramkumar Ramachandra wrote:
> Duy Nguyen wrote:
>> Nobody should ever parse these output
>> with scripts. The color can be generated from color.branch.*.
>
> How do we implement color.branch.(current|local|remote|plain)? In the
> current code, we take a crude appro
Duy Nguyen wrote:
> Nobody should ever parse these output
> with scripts. The color can be generated from color.branch.*.
How do we implement color.branch.(current|local|remote|plain)? In the
current code, we take a crude approach by hand-constructing argc, argv
strings and passing it to cmd_for_
On Tue, May 28, 2013 at 9:24 PM, Ramkumar Ramachandra
wrote:
> Oh, and by the way:
>
> We're pretty close we are to replacing branch -v and branch -vv.
>
> brv = for-each-ref --format='%(HEAD)
> %C(green)%<(*)%(refname:short)%C(reset) %<(*)%(objectname:short)
> %(subject)' refs/heads
>
> brvv = fo
Duy Nguyen wrote:
> It's because you don't pad enough spaces after %(refname:short) so the
> starting point of %(upstream:short) on each line is already unaligned,
> I think.
Yeah, my stupidity. I really meant %>|(30), and that works fine.
--
To unsubscribe from this list: send the line "unsubscr
On Tue, May 28, 2013 at 9:01 PM, Ramkumar Ramachandra
wrote:
> Also, a couple of minor annoyances:
>
> 1. When f-e-r is invoked with refs/tags, we get stray output. Atleast
> it doesn't segfault, thanks to your ignore-commit patch. Maybe
> printing stray output is the right thing to do, as oppos
On Tue, May 28, 2013 at 9:28 PM, Ramkumar Ramachandra
wrote:
> Ramkumar Ramachandra wrote:
>> %>(N) doesn't work properly with f-e-r, and I'm not sure why. I'm not
>> talking about your last patch where you compute * -- that works fine;
>> it's just that %>(N) doesn't when N is a concrete number.
Ramkumar Ramachandra wrote:
> %>(N) doesn't work properly with f-e-r, and I'm not sure why. I'm not
> talking about your last patch where you compute * -- that works fine;
> it's just that %>(N) doesn't when N is a concrete number.
Try this:
%(refname:short)%>(30)%(upstream:short)
(assuming tha
Oh, and by the way:
We're pretty close we are to replacing branch -v and branch -vv.
brv = for-each-ref --format='%(HEAD)
%C(green)%<(*)%(refname:short)%C(reset) %<(*)%(objectname:short)
%(subject)' refs/heads
brvv = for-each-ref --format='%(HEAD)
%C(green)%<(*)%(refname:short)%C(reset) %<(*)%(o
Hi Duy,
I just woke up and started looking at the series: it's rather well
done, and I'm confident that this is the way forward. To reciprocate,
I've done some work at gh:artagnon/git for-each-ref-pretty. See:
https://github.com/artagnon/git/commits/for-each-ref-pretty
There is one major probl
Duy Nguyen wrote:
> Ram, fetch the url above again. Its tip now is 5b4aa27 (for-each-ref:
> introduce format specifier %>(*) and %<(*) - 2013-05-25). Those
> changes make for-each-ref --format a superset of pretty. You can add
> new %(xxx) on top and resend the whole thing to the list for review.
>
On Sat, May 25, 2013 at 1:26 PM, Duy Nguyen wrote:
> On Sat, May 25, 2013 at 5:51 AM, Duy Nguyen wrote:
>> I just had an idea that might bring pretty stuff to for-each-ref with
>> probably reasonable effort, making for-each-ref format a superset of
>> pretty. But I need to clean up my backlog fir
On Sat, May 25, 2013 at 5:51 AM, Duy Nguyen wrote:
> I just had an idea that might bring pretty stuff to for-each-ref with
> probably reasonable effort, making for-each-ref format a superset of
> pretty. But I need to clean up my backlog first. Give me a few days, I
> will show you something (or g
On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
wrote:
> So, while investigating alignment operators in pretty-formats, I found
> out that it's way too much effort and totally not worth it (atleast
> not immediately; we can add it later if we want).
I just had an idea that might bring prett
Junio C Hamano wrote:
> Yes, the aim of the topic should be to make the machinery flexible
> enough so that we can lose -v/-vv implementation and replace them
> with calls to the new machinery with canned set of output format
> templates.
Definitely. I don't want to keep my ugly alias around fore
Junio C Hamano wrote:
> I am having this feeling that we see more and more of this line of
> bad behaviours from some on the list recently to call something that
> is working in which they find itch using unnecessarily derogatory
> terms, and it makes people simply avoid any discussion that starts
Duy Nguyen writes:
> On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
> wrote:
>> There is no need to use a hammer and coerce everything into an atom,
>> or throw everything out the window and start from scratch to conform
>> to pretty-formats perfectly. Let's extend the existing format to
Duy Nguyen wrote:
> Usefulness is one thing. Another is maintenance and in that regard I
> still think we should be able to remove -v and -vv code (not the
> functionality) with this topic.
Why? The topic adds good functionality, doesn't break anything,
doesn't paint us into any corner, and has u
On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
wrote:
> There is no need to use a hammer and coerce everything into an atom,
> or throw everything out the window and start from scratch to conform
> to pretty-formats perfectly. Let's extend the existing format to be
> _useful_ sensibly.
Us
So, while investigating alignment operators in pretty-formats, I found
out that it's way too much effort and totally not worth it (atleast
not immediately; we can add it later if we want). What I want now is
a useable git-branch output. And I think I can say that I've achieved
it.
I currently ha
19 matches
Mail list logo
