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
On Tue, Jun 4, 2013 at 7:52 PM, Ramkumar Ramachandra artag...@gmail.com 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
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 unsubscribe
On Tue, May 28, 2013 at 9:24 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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
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)
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 that you
On Tue, May 28, 2013 at 9:28 PM, Ramkumar Ramachandra
artag...@gmail.com 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
On Tue, May 28, 2013 at 9:01 PM, Ramkumar Ramachandra
artag...@gmail.com 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
On Sat, May 25, 2013 at 5:51 AM, Duy Nguyen pclo...@gmail.com 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
On Sat, May 25, 2013 at 1:26 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, May 25, 2013 at 5:51 AM, Duy Nguyen pclo...@gmail.com 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
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.
You
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
On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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
Duy Nguyen pclo...@gmail.com writes:
On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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
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
On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
artag...@gmail.com 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
19 matches
Mail list logo
