Junio C Hamano wrote:
> $ git show -s --format='%CredAnd%CyellowAreNotTheSameColor'
Ouch, this is quite a disaster.
> It would have been much saner if we started from %(color:yellow),
> %(subject), etc., i.e. have a single long-hand magic introducer
> %(...), and added a set of often-used sh
Ramkumar Ramachandra writes:
> ... %C(...) is
> different in that it doesn't actually output anything, but changes the
> color of tokens following it. While I'm not opposed to %(color:...), I
> would prefer a color syntax that is different from other-token syntax,
> like in pretty-formats.
You m
Junio C Hamano wrote:
> If %(authordate) is "I want to see the author date here", and
> %(authordate:short) is "I want to see the author date here in the
> short form", you would expect "I want colored output in green" to be
> spelled as %(color:green), or something, perhaps?
Last time, we almost
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> ... users of for-each-ref format will be _more_ familiar with
>> formats used by for-each-ref, and it would make a lot more sense to
>> keep the syntactic resemblance between existing features to show
>> magic things in for-each-ref and the
Junio C Hamano wrote:
> ... users of for-each-ref format will be _more_ familiar with
> formats used by for-each-ref, and it would make a lot more sense to
> keep the syntactic resemblance between existing features to show
> magic things in for-each-ref and the new feature to show color
> (which is
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> This patch is about for-each-ref and your series does not seem to
>> aim to unify it in any way with pretty-formats, so I would have
>> expected an enhancement in line with the former, not the latter.
>
> While I might never attempt a unific
Junio C Hamano wrote:
> This patch is about for-each-ref and your series does not seem to
> aim to unify it in any way with pretty-formats, so I would have
> expected an enhancement in line with the former, not the latter.
While I might never attempt a unification again, there's no harm in
getting
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra writes:
>>
>>> Enhance 'git for-each-ref' with color formatting options. You can now
>>> use the following format in for-each-ref:
>>>
>>> %C(green)%(refname:short)%C(reset)
>>
>> So far, every magic for-each-ref tak
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> Enhance 'git for-each-ref' with color formatting options. You can now
>> use the following format in for-each-ref:
>>
>> %C(green)%(refname:short)%C(reset)
>
> So far, every magic for-each-ref takes were of form %(...); was
> there a rea
Ramkumar Ramachandra writes:
> Enhance 'git for-each-ref' with color formatting options. You can now
> use the following format in for-each-ref:
>
> %C(green)%(refname:short)%C(reset)
So far, every magic for-each-ref takes were of form %(...); was
there a reason why this had to be %C(...), no
Enhance 'git for-each-ref' with color formatting options. You can now
use the following format in for-each-ref:
%C(green)%(refname:short)%C(reset)
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4 +++-
builtin/for-each-ref.c | 23 +++
On Fri, Sep 27, 2013 at 8:10 AM, Ramkumar Ramachandra
wrote:
> Enhance 'git for-each-ref' with color formatting options. You can now
> use the following format in for-each-ref:
>
> %C(green)%(refname:short)%C(reset)
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> Documentation/git-for-each-re
Enhance 'git for-each-ref' with color formatting options. You can now
use the following format in for-each-ref:
%C(green)%(refname:short)%C(reset)
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4 +++-
builtin/for-each-ref.c | 23 +++
John Keeping wrote:
> Section 6.7.9 of the C11 standard says:
>
> If an object that has automatic storage duration is not initialized
> explicitly, its value is indeterminate.
Ah, thanks. I'll initialize it to an empty string.
>> More importantly, aren't there numerous instances of this
On Sat, May 25, 2013 at 1:50 PM, Ramkumar Ramachandra
wrote:
> Antoine Pelisse wrote:
>> Is it not possible for "color" to be used uninitialized here ?
>
> My compiler didn't complain; what am I missing? Doesn't the
> declaration char color[COLOR_MAXLEN]; initialize an empty string?
As John said
On Sat, May 25, 2013 at 05:20:29PM +0530, Ramkumar Ramachandra wrote:
> Antoine Pelisse wrote:
> > Is it not possible for "color" to be used uninitialized here ?
>
> My compiler didn't complain; what am I missing? Doesn't the
> declaration char color[COLOR_MAXLEN]; initialize an empty string?
Wh
David Aguilar wrote:
> Can you please also update Documentation/?
Yeah, will do in the re-roll. Duy is bringing in pretty-formats.
We'll probably need a separate document called pretty-ref-formats or
some such thing.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
Antoine Pelisse wrote:
> Is it not possible for "color" to be used uninitialized here ?
My compiler didn't complain; what am I missing? Doesn't the
declaration char color[COLOR_MAXLEN]; initialize an empty string?
More importantly, aren't there numerous instances of this in the
codebase?
--
To un
On Fri, May 24, 2013 at 10:19 AM, Ramkumar Ramachandra
wrote:
> Since 'git branch' misses important options like --sort, --count, and
> --format that are present in 'git for-each-ref'. Until we are in a
> position to fix 'git branch', let us enhance the 'git for-each-ref'
> format so it can atlea
On Fri, May 24, 2013 at 7:19 AM, Ramkumar Ramachandra
wrote:
> Since 'git branch' misses important options like --sort, --count, and
> --format that are present in 'git for-each-ref'. Until we are in a
> position to fix 'git branch', let us enhance the 'git for-each-ref'
> format so it can atleas
On Fri, May 24, 2013 at 4:19 PM, Ramkumar Ramachandra
wrote:
> @@ -928,12 +936,22 @@ static void emit(const char *cp, const char *ep)
> static void show_ref(struct refinfo *info, const char *format, int
> quote_style)
> {
> const char *cp, *sp, *ep;
> + char color[COLOR_MAXLEN];
>
Since 'git branch' misses important options like --sort, --count, and
--format that are present in 'git for-each-ref'. Until we are in a
position to fix 'git branch', let us enhance the 'git for-each-ref'
format so it can atleast colorize output.
You can use the following format in for-each-ref:
22 matches
Mail list logo
