On Tue, Oct 23, 2007 at 12:55:44AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 22 Oct 2007, Peter Baumann wrote:
>
> > Wouldn't it make more sense to implement the diff coloring inside git
> > apply so that you could use something like
> >
> > diff file1 file2|git apply --color
> >
> > to make the generated diff with colors [1]? It already implements the
> > same semantic for generating a diffstat, using
> >
> > diff file1 file2|git apply --stat
>
> No. In both cases, "git diff" realises that the output is no terminal,
> and switches off color generation. (Just try with diff.color=true instead
> of =auto.)
>
I didn't mean git-diff here, instead I meant diff, so no coloring involved
on the diff side. The git-apply would be enhanced to do the coloring on
every diff it gets on its STDIN.
In the git-add -i case, the perl script whould do something along these
lines:
foreach my $file (@files) {
# read in the diff of a file *WITHOUT* using color
@diff = `git-diff-files $file`;
# ... store it away for later use in hunk selection ...
# print out a nice colored diff for the user
`echo @diff | git apply --color`
}
Instead of handcoding the colorization in the git-add--interactive perl
script, just enhance git-apply to do the colorization *after the fact* for
you on _any_ patch you throw at it in its STDIN.
-Peter
-
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
