On Mon, Dec 17, 2012 at 12:03:40PM -0800, Junio C Hamano wrote:
> > So no, I do not think you can cover every conceivable case. But having
> > git-log respect --color and the usual color.* variables for this feature
> > seems like the only sane default. It makes the easy cases just work, and
> > t
Jeff King writes:
> If "git frotz" wants to have a separate "color.frotz" option to override
> that, then they would need to implement that themselves either with or
> without your patch. I do not think its presence makes things any harder.
That _was_ (but no longer is) exactly my point. Eh, ra
On Mon, Dec 17, 2012 at 11:34:48AM -0800, Junio C Hamano wrote:
> > Yeah, that should definitely be documented. I wonder if it should
> > actually respect color.diff, which is what "log" usually uses (albeit
> > mostly for the diff itself, we have always used it for the graph and for
> > the "comm
Jeff King writes:
> On Mon, Dec 17, 2012 at 06:44:10PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> > if (!end)
>> > return 0;
>> > - color_parse_mem(placeholder + 2,
>> > - end - (place
On Mon, Dec 17, 2012 at 12:40:55AM -0800, Junio C Hamano wrote:
> +# %C(auto,...) should trump --color=always
> +#
> +# NEEDSWORK: --color=never should also be tested but we need to run a
> +# similar test under pseudo-terminal with test_terminal which is too
> +# much hassle for its worth.
> +
>
On Mon, Dec 17, 2012 at 06:44:10PM +0700, Nguyen Thai Ngoc Duy wrote:
> > if (!end)
> > return 0;
> > - color_parse_mem(placeholder + 2,
> > - end - (placeholder + 2),
> > +
On Mon, Dec 17, 2012 at 3:40 PM, Junio C Hamano wrote:
> Traditionally, %C(color attr) always emitted the ANSI color
> sequence; it was up to the scripts that wanted to conditionally
> color their output to omit %C(...) specifier when they do not want
> colors.
>
> Optionally allow "auto," to be p
7 matches
Mail list logo
