Question: Getting 'git diff' to generate /usr/bin/diff output

Question: Getting 'git diff' to generate /usr/bin/diff output

[norm]

I am trying to learn how to use git, and am having difficulty using 'git diff'.

I can't deal with its output very well. What I would really like to do is apply
/usr/lib/diff. Would some kind soul be willing to tell me if there is a way to
do that, short of making a backup copy of the relevant file, and then doing
'git checkout'. Maybe the '--ext-diff' argument to 'git diff' will do that,
but I can't figure out how to use it.

Thank you, most kindly.

Context:

    Operating System: Red Hat Enterprise Linux Workstation release 6.8

    git version: 2.5.1.454.g1616360

 Norman Shapiro

Re: Question: Getting 'git diff' to generate /usr/bin/diff output

[Perry Hutchison]

norm@dad.org wrote:

> I am trying to learn how to use git, and am having difficulty
> using 'git diff'.
>
> I can't deal with its output very well. What I would really like
> to do is apply /usr/lib/diff.
                      ^^^

For starters, when using the full pathname, you'll need to spell it
correctly :)

> Would some kind soul be willing to tell me if there is a way to
> do that, short of making a backup copy of the relevant file, and
> then doing 'git checkout'. Maybe the '--ext-diff' argument to
> 'git diff' will do that, but I can't figure out how to use it.
> ...
>     git version: 2.5.1.454.g1616360

'git cat' would be simpler than making a backup and using 'git checkout',
but for this use case there's a better way even than that.

Google is your friend when you can't figure something out from (or
find the right part of) a program's own documentation.  A search for

    git "external diff program"

(including the quotes) found several references.

One possible complication:  It's likely that the command parameters
which git passes to an external diff program are not exactly what
/usr/bin/diff requires.  The solution to that sort of problem is to
write a very short executable script that rearranges the parameters
as needed, and specify that script (instead of /usr/bin/diff itself)
as the external diff program.

Re: Question: Getting 'git diff' to generate /usr/bin/diff output

[Johannes Schindelin]

Hi,

[Perry, my mailer could not find your MX record, so I am sorry I had to
drop you from the explicit To:...]

On Sat, 16 Jul 2016, Perry Hutchison wrote:

> norm@dad.org wrote:
> 
> > Would some kind soul be willing to tell me if there is a way to
> > do that, short of making a backup copy of the relevant file, and
> > then doing 'git checkout'. Maybe the '--ext-diff' argument to
> > 'git diff' will do that, but I can't figure out how to use it.
> > ...
> >     git version: 2.5.1.454.g1616360
> 
> 'git cat' would be simpler than making a backup and using 'git checkout',
> but for this use case there's a better way even than that.

$ git cat
git: 'cat' is not a git command. See 'git --help'.

;-)

You probably meant `git cat-file blob <SHA-1>`.

> Google is your friend when you can't figure something out from (or
> find the right part of) a program's own documentation.  A search for
> 
>     git "external diff program"
> 
> (including the quotes) found several references.
> 
> One possible complication:  It's likely that the command parameters
> which git passes to an external diff program are not exactly what
> /usr/bin/diff requires.  The solution to that sort of problem is to
> write a very short executable script that rearranges the parameters
> as needed, and specify that script (instead of /usr/bin/diff itself)
> as the external diff program.

To spell it out, you probably referred to the --ext-diff option:
https://github.com/git/git/blob/v2.9.2/Documentation/diff-options.txt#L528-L531

This option can be used with any diff-producing Git command, but it
requires a .gitattribute setting together with the corresponding
diff.external setting in the config.

A better method might be to use the `git difftool` command, e.g.

	git difftool -x diff

You can also inspect the diff of a commit, using the ^! suffix, e.g.

	git difftool -x diff origin/master~3^!

If you want to avoid the prompt and get the complete diff for all files in
one go, you will have to write a small script as indicated, e.g.

	printf '#!/bin/sh\n\n/usr/bin/diff -r "$@"\n' >my-diff.sh
	chmod a+x my-diff.sh
	git difftool -d -x $PWD/my-diff.sh HEAD^!

I did write all of this in the mail program, so I highly recommend reading
the man page of the difftool e.g. to understand the meaning of the -d
option, so that you can fix any problems with my examples yourself.

Ciao,
Johannes

Re: Question: Getting 'git diff' to generate /usr/bin/diff output

[René Scharfe]

Am 16.07.2016 um 21:12 schrieb norm@dad.org:
> I am trying to learn how to use git, and am having difficulty using 'git diff'.
>
> I can't deal with its output very well.

The other replies covered how to use the system's own diff instead. 
Just curious: What makes using git diff difficult and its output hard to 
deal with for you?

Thanks,
René

Re: Question: Getting 'git diff' to generate /usr/bin/diff output

[norm]

<l.s.r@web.de> writes:
>
>The other replies covered how to use the system's own diff instead.
>Just curious: What makes using git diff difficult and its output hard to
>deal with for you?

In decreasing importance order:

I am 84 years old. I have been using /usr/bin/diff for more than four decades.
And having to learn how to read the output of 'git diff' makes learning how
to use git a more difficult trick for this old dog to learn. True, the diff of
today is very different from the diff of 1972, but the changes happened
gradually.

I have scripts which process the output of /usr/bin/diff.

'git diff' outputs escape characters which clutter my terminal. Yes, I can sed
them out, but then why are they there?


    Norman Shapiro

Re: Question: Getting 'git diff' to generate /usr/bin/diff output

[Johannes Schindelin]

Hi Norm,

On Sun, 17 Jul 2016, norm@dad.org wrote:

> <l.s.r@web.de> writes:
> >
> >The other replies covered how to use the system's own diff instead.
> >Just curious: What makes using git diff difficult and its output hard to
> >deal with for you?
> 
> In decreasing importance order:
> 
> I am 84 years old.

Wow. Chapeau! I am impressed.

> I have been using /usr/bin/diff for more than four decades.  And having
> to learn how to read the output of 'git diff' makes learning how to use
> git a more difficult trick for this old dog to learn. True, the diff of
> today is very different from the diff of 1972, but the changes happened
> gradually.

Curious: do you use context diff (GNU diff's default) or unified diffs?

> I have scripts which process the output of /usr/bin/diff.

Even more curious: what do those scripts do? Maybe they do things that we
either can already do with Git's diff, or that we can teach Git.

> 'git diff' outputs escape characters which clutter my terminal. Yes, I
> can sed them out, but then why are they there?

Those are most likely the ANSI sequences to add color. Can you call Git
with the --no-color option and see whether the escape characters go away?

Ciao,
Johannes

[PATCH] pager: disable color when pager is "more"

[Eric Wong]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 17 Jul 2016, norm@dad.org wrote:
> > 'git diff' outputs escape characters which clutter my terminal. Yes, I
> > can sed them out, but then why are they there?
> 
> Those are most likely the ANSI sequences to add color. Can you call Git
> with the --no-color option and see whether the escape characters go away?

Norm: do you have PAGER=more set by any chance?
Perhaps changing it to "less" will allow you to preserve colors.

I saw a similar or identical problem during my vacation in
FreeBSD-land.  Perhaps the out-of-the-box experience can be
improved:

-----8<-----
Subject: [PATCH] pager: disable color when pager is "more"

more(1) traditionally cannot handle colors.

On FreeBSD 10.3, a new user ~/.profile explicitly sets
PAGER=more, but does not configure it to display colors, leading
to a bad out-of-the-box experience with escape sequences being
seen by the user.

In the FreeBSD 10.3 case, /usr/bin/more is actually a hardlink
to /usr/bin/less and capable of handling colors.  While we could
set MORE=FRX, this breaks other more(1) implementations,
including the one provided by util-linux on common GNU/Linux
systems.

So take the safe route and assume anybody still using more(1)
today can live with monochrome output, but acknowledge 'R'
in the MORE environment variable if it was set by the user.

Signed-off-by: Eric Wong <e@80x24.org>
---
 environment.c |  2 +-
 pager.c       | 11 +++++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/environment.c b/environment.c
index ca72464..cfb56fd 100644
--- a/environment.c
+++ b/environment.c
@@ -41,7 +41,7 @@ size_t packed_git_limit = DEFAULT_PACKED_GIT_LIMIT;
 size_t delta_base_cache_limit = 96 * 1024 * 1024;
 unsigned long big_file_threshold = 512 * 1024 * 1024;
 const char *pager_program;
-int pager_use_color = 1;
+int pager_use_color = -1;
 const char *editor_program;
 const char *askpass_program;
 const char *excludes_file;
diff --git a/pager.c b/pager.c
index 4bc0481..3110df4 100644
--- a/pager.c
+++ b/pager.c
@@ -80,6 +80,17 @@ void setup_pager(void)
 	if (!pager)
 		return;
 
+	if (pager_use_color < 0 && !strcmp(pager, "more")) {
+		const char *more = getenv("MORE");
+
+		/*
+		 * MORE=R does not work everywhere, so we cannot set it,
+		 * but we can respect it if set.
+		 */
+		if (!more || !strchr(more, 'R'))
+			pager_use_color = 0;
+	}
+
 	/*
 	 * force computing the width of the terminal before we redirect
 	 * the standard output to the pager.
-- 
EW

Re: [PATCH] pager: disable color when pager is "more"

[Jeff King]

On Mon, Jul 18, 2016 at 09:19:07AM +0000, Eric Wong wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 17 Jul 2016, norm@dad.org wrote:
> > > 'git diff' outputs escape characters which clutter my terminal. Yes, I
> > > can sed them out, but then why are they there?
> > 
> > Those are most likely the ANSI sequences to add color. Can you call Git
> > with the --no-color option and see whether the escape characters go away?
> 
> Norm: do you have PAGER=more set by any chance?
> Perhaps changing it to "less" will allow you to preserve colors.
> 
> I saw a similar or identical problem during my vacation in
> FreeBSD-land.  Perhaps the out-of-the-box experience can be
> improved:
> 
> -----8<-----
> Subject: [PATCH] pager: disable color when pager is "more"

This is the tip of a smaller iceberg. See

  http://public-inbox.org/git/52D87A79.6060600%40rawbw.com/t/#u

for more discussion, and some patches that fix more cases (like "LESS"
without "R", or "more" that _does_ understand "R"). I think it was
discarded as being a little too intimate with the details of pagers, but
it does suck that the out-of-the-box experience on FreeBSD is not good.
Maybe we should revisit it.

-Peff

Re: [PATCH] pager: disable color when pager is "more"

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Mon, Jul 18, 2016 at 09:19:07AM +0000, Eric Wong wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> > On Sun, 17 Jul 2016, norm@dad.org wrote:
>> > > 'git diff' outputs escape characters which clutter my terminal. Yes, I
>> > > can sed them out, but then why are they there?
>> > 
>> > Those are most likely the ANSI sequences to add color. Can you call Git
>> > with the --no-color option and see whether the escape characters go away?
>> 
>> Norm: do you have PAGER=more set by any chance?
>> Perhaps changing it to "less" will allow you to preserve colors.
>> 
>> I saw a similar or identical problem during my vacation in
>> FreeBSD-land.  Perhaps the out-of-the-box experience can be
>> improved:
>> 
>> -----8<-----
>> Subject: [PATCH] pager: disable color when pager is "more"
>
> This is the tip of a smaller iceberg. See
>
>   http://public-inbox.org/git/52D87A79.6060600%40rawbw.com/t/#u
>
> for more discussion, and some patches that fix more cases (like "LESS"
> without "R", or "more" that _does_ understand "R"). I think it was
> discarded as being a little too intimate with the details of pagers, but
> it does suck that the out-of-the-box experience on FreeBSD is not good.
> Maybe we should revisit it.

Yup, the three-patch series at

    http://public-inbox.org/git/20140117041430.GB19551%40sigill.intra.peff.net/

would be a safe starting point that is low-impact.  I think what
ended up being discarded was a more elaborate side topic that
started from exploring the possibility of checking if LESS has 'R'
in it to see if it is possible to help people with LESS that does
not allow coloring explicitly exported.

I do not think the approach in the same thread suggested by Kyle

  http://public-inbox.org/git/62DB6DEF-8B39-4481-BA06-245BF45233E5%40gmail.com/

is too bad, either.

Re: [PATCH] pager: disable color when pager is "more"

[Jeff King]

On Mon, Jul 18, 2016 at 10:19:09AM -0700, Junio C Hamano wrote:

> > This is the tip of a smaller iceberg. See
> >
> >   http://public-inbox.org/git/52D87A79.6060600%40rawbw.com/t/#u
> >
> > for more discussion, and some patches that fix more cases (like "LESS"
> > without "R", or "more" that _does_ understand "R"). I think it was
> > discarded as being a little too intimate with the details of pagers, but
> > it does suck that the out-of-the-box experience on FreeBSD is not good.
> > Maybe we should revisit it.
> 
> Yup, the three-patch series at
> 
>     http://public-inbox.org/git/20140117041430.GB19551%40sigill.intra.peff.net/
> 
> would be a safe starting point that is low-impact.  I think what
> ended up being discarded was a more elaborate side topic that
> started from exploring the possibility of checking if LESS has 'R'
> in it to see if it is possible to help people with LESS that does
> not allow coloring explicitly exported.

Yeah, I only re-skimmed the thread, but I had the same impression. I am
traveling the next few days, so I will probably not get to it soon.  If
anybody wants to pick up and rebase/polish those patches as necessary,
be my guest.

-Peff

Re: [PATCH] pager: disable color when pager is "more"

[Eric Wong]

Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
> > On Mon, Jul 18, 2016 at 09:19:07AM +0000, Eric Wong wrote:
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >> > On Sun, 17 Jul 2016, norm@dad.org wrote:
> >> > > 'git diff' outputs escape characters which clutter my terminal. Yes, I
> >> > > can sed them out, but then why are they there?
> >> > 
> >> > Those are most likely the ANSI sequences to add color. Can you call Git
> >> > with the --no-color option and see whether the escape characters go away?
> >> 
> >> Norm: do you have PAGER=more set by any chance?
> >> Perhaps changing it to "less" will allow you to preserve colors.
> >> 
> >> I saw a similar or identical problem during my vacation in
> >> FreeBSD-land.  Perhaps the out-of-the-box experience can be
> >> improved:
> >> 
> >> -----8<-----
> >> Subject: [PATCH] pager: disable color when pager is "more"
> >
> > This is the tip of a smaller iceberg. See
> >
> >   http://public-inbox.org/git/52D87A79.6060600%40rawbw.com/t/#u
> >
> > for more discussion, and some patches that fix more cases (like "LESS"
> > without "R", or "more" that _does_ understand "R"). I think it was
> > discarded as being a little too intimate with the details of pagers, but
> > it does suck that the out-of-the-box experience on FreeBSD is not good.
> > Maybe we should revisit it.

Yes; I'd prefer not to get too intimate with the details of
pagers, either, and I think we should err on the side of
monochrome for systems we do not know much about.

> Yup, the three-patch series at
> 
>     http://public-inbox.org/git/20140117041430.GB19551%40sigill.intra.peff.net/

I am not a fan of adding #ifdefs for platform-specific things;
so I prefer starting with my original patch to disable colors
for "more".  (or, even disable colors for everything which
is not "less" or "lv")
 
> would be a safe starting point that is low-impact.  I think what
> ended up being discarded was a more elaborate side topic that
> started from exploring the possibility of checking if LESS has 'R'
> in it to see if it is possible to help people with LESS that does
> not allow coloring explicitly exported.

Heh... (see below)

> I do not think the approach in the same thread suggested by Kyle
> 
>   http://public-inbox.org/git/62DB6DEF-8B39-4481-BA06-245BF45233E5%40gmail.com/
> 
> is too bad, either.

I like Kyle's suggestion, and I think that can be a good
transition from your original patch to move pager
configuration into the build:

https://public-inbox.org/git/xmqq61piw4yf.fsf@gitster.dls.corp.google.com/

I've updated just that and pushed just that to the "pager-build"
topic of git://bogomips.org/git-svn

So I'd prefer we drop the later automatic header generation
changes that got squashed into later iterations.


Unfortunately, it looks like that all got lost in Jeff's
13-patch "makefile refactoring" topic starting at:

https://public-inbox.org/git/20140205174823.GA15070@sigill.intra.peff.net/

Yeah, we tend to get sidetracked :x

Re: Question: Getting 'git diff' to generate /usr/bin/diff output

[norm]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>A better method might be to use the `git difftool` command, e.g.
>
>git difftool -x diff

Something like:

git difftool --no-prompt --extcmd=diff

or like:

git difftool --no-prompt --extcmd="diff -b" "$@"

works great for me. Thank you very much indeed!

    Norman Shapiro