How do I view a git diff in a text editor?

问题

How do I view a git diff in a plain old text editor like Atom? I don't want to set up or use a diff tool, I just want to view the diff in any basic text editor.

Answers to other questions I've seen talk about setting up a diff tool, but I just want to specify some random text editor.

Side question:

What's the difference between a diff tool and any text editor?

回答1:

How do I view a git diff in a plain old text editor like Atom? I don't want to set up or use a diff tool, I just want to view the diff in any basic text editor.

Diff output is just text, so you can redirect it to a file and open that file, or (depending on the editor and platform) pipe the input directly to the editor.

If you did want run your editor as the diff tool, the documentation describes how the editor is invoked. You may want a wrapper script to invoke atom with the environment variables in the correct place on the command line.

Side question: What's the difference between a diff tool and any text editor?

A generic text editor is unlikely to display diffs as nicely as a dedicated tool. At least, if it recognizes the format, it may highlight the diff-specific parts.

A real difftool will generally give you the opportunity to see both the old and new versions of the file, as well as showing visually where the changes sit. It may highlight intra-line changes too (the diff itself is line-based).

I'm generally against pictures of text, but since we're really discussing the interface ...

output from git diff opened in text editor: This is hardly different than just reading the diff in the terminal, so I don't see much benefit. It does highlight the index line, but that's only really useful if I'm scanning through multiple hunks in a single diff.
GVim fugitive plugin showing the same change: This is the view from inside my editor with the fugitive plugin. You can see the intra-line highlight where I removed a space from the join line. It'll even update live if I keep typing in the right pane. This is also the only one that correctly syntax highlights the source code.
same change opened in meld with git difftool This is the friendliest view of how a change fits into the whole file IMO.

回答2:

TL;DR: Git itself does not know anything about other commands, so you have to provide an auxiliary set of instructions to Git to tell it: to use program X as a difftool, do _____. Your best bet is to find instructions already constructed by someone else, as in the comment EncryptedWatermelon added to his own answer, but failing that, well, see below.

See Useless's answer for several practical tips.

Note that as far as Git itself is concerned, to put it as simply as possible, diff means compare two revisions. The two revisions can be two commits, or one commit and your work-tree contents, for instance. Git has some additional special cases so that you can use it as a fancier version of the standard Unix/Linux diff command as well, but mostly, it's two revisions, each of which is a whole set of files:

If the left-side revision has a file named F and the right-side revision has a file named F, Git will compare the contents of the two versions of F.
If the left-side has a file D and it's just not there in the right-side revision, file D was deleted.
If the left-side has no file A, but there is a file A in the right-side revision, file A was added.
If you enable rename-detection—which is the default since Git 2.9—Git will, in cases of added-and-deleted files, try to see if maybe a newly added file is actually mostly the same as an old-but-deleted file, and if so, report this as a renamed file, with old name D (deleted) and new name A (added). Git then goes on to compare the contents of left-side D with those of right-side A as well.
When comparing the contents of files, if everything is the same, Git generally just says nothing at all about the file. Otherwise, you can have Git give you a set of instructions of the form "remove this line" and/or "add this other line". Following the instructions will transform the old version of the file into the new version of the file. These instructions are not necessarily what anyone actually did! They will just achieve the same result. (Usually there's only one obvious way to achieve the result, so that turns out to be what someone did.)

With that in mind, here's what git difftool does:

First, it has Git compare the two revisions to generate a list of files-that-have-changes, while suppressing the actual comparisons of those files.
Then, with the list of changed files—the set of names F that were in both revisions but did not match in the two revisions—it makes a copy of the left-side revision version of the file, and a copy of the right-side revision version. It must make these copies in most cases because files stored inside Git are kept in a frozen and compressed form that only Git can actually read. Git has to uncompress / unfreeze them, "rehydrating" the internal freeze-dried form of the file, so that other programs can read it.

In a few cases, such as when comparing a particular commit to the work-tree, it may just use the work-tree copy when appropriate. It may still make its own copy. You get no actual promise one way or the other here.
Now that there are two copies of the file, Git uses a helper program to launch your chosen diff tool. This helper program is given several pieces of information, such as:
- the name of each temporary copy
- the original name of the file (the temporary copy typically has some ugly temporary name like .tmp-123456, for instance)
The helper program's job is to run the diff tool so that it displays these files in a manner that is friendly to the user. It must then wait for the tool to indicate that the user is finished viewing the files, and find out whether the user has indicated a desire to cancel viewing files, or to proceed on to the next file-pair.

This is the helper program. It is a relatively simple shell script, weighing in at just over 100 lines. But it uses more shell scripts: in particular, it uses this larger mergetool helper library, which weighs in at over 450 lines of shell script.

To provide your own tool, you must—for best usage anyway—write shell script that is used by the second (merge helper) library in conjunction with the first script that provides the knowledge about how to run your chosen tool. The key elements of this interaction are:

opening the two files
showing a more useful name than .tmpwhatever
detecting when and whether the user wants to go on to the next diff, or quit.

The two existing libraries of shell script helper code have some fallbacks so that if your program is relatively simple to use, the existing helpers can run it themselves. They just need to know where the executable is and what arguments to pass and whether to trust its exit code. You can set these up with git config by setting difftool.name.cmd and mergetool.name.trustExitCode. For instance:

git config --global difftool.foo.cmd '<path> "$LOCAL" "$REMOTE"'
git config --global mergetool.foo.trustExitCode true

would be OK (but not that great: the file names will be weird and useless) if the command at path exits zero for "go on to next diff" and nonzero for "quit now".

回答3:

git diff will display in your console if the output is short, otherwise it will go to your pager. ie less or more

git difftool will display in tkdiff, xxdiff, meld, compare gvimdiff,... or whatever you set

Difftools often let your edit the file while the pager is read-only

回答4:

A diff tool (e.g: http://meldmerge.org/) will show you the diff in 2, 3 or even 4 panels (your version, remote version, merged version, ancestor version).

Opening diff on a text editor (this is my preference) will show you diff special characters indicating addition, deletion, and modifications of content. As well as some context boundary information.

来源：https://stackoverflow.com/questions/58663161/how-do-i-view-a-git-diff-in-a-text-editor

标签

git

git-diff