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

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

                      ^^^

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

'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.

Hi,

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

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

;-)

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

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

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

Am 16.07.2016 um 21:12 schrieb [email protected]:

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é

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

Hi Norm,

Wow. Chapeau! I am impressed.

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

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.

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

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.

---
 environment.c |  2 +-
 pager.c       | 11 +++++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)

index ca72464..cfb56fd 100644
@@ -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;

index 4bc0481..3110df4 100644
@@ -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

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

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.

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

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.

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")

Heh... (see below)

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/[email protected]/

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/[email protected]/

Yeah, we tend to get sidetracked :x