René Scharfe d7b97b7185 diff: let external diffs report that changes are uninteresting
The options --exit-code and --quiet instruct git diff to indicate
whether it found any significant changes by exiting with code 1 if it
did and 0 if there were none.  Currently this doesn't work if external
diff programs are involved, as we have no way to learn what they found.

Add that ability in the form of the new configuration options
diff.trustExitCode and diff.<driver>.trustExitCode and the environment
variable GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE.  They pair with the config
options diff.external and diff.<driver>.command and the environment
variable GIT_EXTERNAL_DIFF, respectively.

The new options are off by default, keeping the old behavior.  Enabling
them indicates that the external diff returns exit code 1 if it finds
significant changes and 0 if it doesn't, like diff(1).

The name of the new options is taken from the git difftool and mergetool
options of similar purpose.  (There they enable passing on the exit code
of a diff tool and to infer whether a merge done by a merge tool is
successful.)

The new feature sets the diff flag diff_from_contents in
diff_setup_done() if we need the exit code and are allowed to call
external diffs.  This disables the optimization that avoids calling the
program with --quiet.  Add it back by skipping the call if the external
diff is not able to report empty diffs.  We can only do that check after
evaluating the file-specific attributes in run_external_diff().

If we do run the external diff with --quiet, send its output to
/dev/null.

I considered checking the output of the external diff to check whether
its empty.  It was added as 11be65cfa4 (diff: fix --exit-code with
external diff, 2024-05-05) and quickly reverted, as it does not work
with external diffs that do not write to stdout.  There's no reason why
a graphical diff tool would even need to write anything there at all.

I also considered using a non-zero exit code for empty diffs, which
could be done without adding new configuration options.  We'd need to
disable the optimization that allows git diff --quiet to skip calling
external diffs, though -- that might be quite surprising if graphical
diff programs are involved.  And assigning the opposite meaning of the
exit codes compared to diff(1) and git diff --exit-code to the external
diff can cause unnecessary confusion.

Suggested-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-10 09:20:46 -07:00
2023-12-14 14:38:07 -08:00
2023-11-26 10:07:06 +09:00
2023-11-26 10:10:48 +09:00
2024-05-03 10:36:59 -07:00
2024-05-27 11:20:00 -07:00
2024-04-25 10:34:24 -07:00
2024-02-12 09:32:41 -08:00
2024-03-28 14:13:50 -07:00
2024-06-06 12:49:23 -07:00
2023-12-26 12:04:32 -08:00
2023-11-26 10:10:48 +09:00
2024-03-28 14:13:50 -07:00
2024-01-23 10:40:10 -08:00
2023-11-26 10:10:48 +09:00
2024-03-28 14:13:50 -07:00
2024-06-06 12:49:23 -07:00
2024-06-06 12:49:23 -07:00
2023-07-06 11:54:48 -07:00
2024-04-05 15:21:14 -07:00
2024-04-05 15:21:14 -07:00
2024-04-29 20:42:30 +02:00
2024-04-19 12:38:50 +02:00
2024-06-06 12:49:23 -07:00
2024-06-06 12:49:23 -07:00
2023-04-17 21:15:56 +02:00
2023-11-26 10:07:05 +09:00
2024-05-30 17:18:43 -07:00
2024-05-03 10:36:59 -07:00
2023-11-26 10:07:05 +09:00
2023-06-28 14:06:39 -07:00
2024-03-28 14:13:50 -07:00
2023-06-28 14:06:39 -07:00
2024-04-19 12:38:50 +02:00
2023-11-26 10:07:05 +09:00
2023-11-26 10:07:05 +09:00
2023-11-26 10:07:05 +09:00
2023-11-26 10:07:05 +09:00
2023-10-02 14:57:38 -07:00
2024-05-17 10:33:39 -07:00
2024-06-06 12:49:23 -07:00
2024-02-26 09:35:40 -08:00
2024-03-28 14:13:50 -07:00
2024-02-26 15:34:01 -08:00
2024-02-26 15:34:01 -08:00
2024-05-17 10:33:39 -07:00
2024-03-28 14:13:50 -07:00
2023-11-26 10:07:05 +09:00
2024-05-17 10:33:39 -07:00
2024-04-05 15:21:14 -07:00
2024-05-17 10:33:39 -07:00
2024-05-30 17:18:43 -07:00
2024-06-06 12:49:23 -07:00
2024-04-23 11:52:41 -07:00
2024-06-06 12:49:23 -07:00
2024-06-06 12:49:23 -07:00
2024-04-29 20:42:30 +02:00
2023-11-26 10:07:05 +09:00
2024-03-02 11:12:16 -08:00
2023-12-27 14:52:24 -08:00
2023-09-15 17:08:46 -07:00
2024-04-05 10:49:49 -07:00
2024-04-19 12:38:37 +02:00
2024-05-17 10:33:39 -07:00
2024-05-17 10:33:39 -07:00
2023-11-26 10:07:05 +09:00
2023-03-17 14:03:09 -07:00
2024-05-23 11:04:27 -07:00
2024-05-23 11:04:27 -07:00
2024-03-28 14:13:50 -07:00
2024-03-28 14:13:50 -07:00
2024-03-28 14:13:50 -07:00
2024-06-06 12:49:23 -07:00
2023-06-28 14:06:39 -07:00
2024-04-05 15:16:27 -07:00
2023-11-26 10:07:05 +09:00
2023-11-26 10:07:05 +09:00
2023-04-04 14:28:27 -07:00
2023-05-17 10:11:41 -07:00

Build status

Git - fast, scalable, distributed revision control system

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.

Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). It was originally written by Linus Torvalds with help of a group of hackers around the net.

Please read the file INSTALL for installation instructions.

Many Git online resources are accessible from https://git-scm.com/ including full documentation and Git related tools.

See Documentation/gittutorial.txt to get started, then see Documentation/giteveryday.txt for a useful minimum set of commands, and Documentation/git-<commandname>.txt for documentation of each command. If git has been correctly installed, then the tutorial can also be read with man gittutorial or git help tutorial, and the documentation of each command with man git-<commandname> or git help <commandname>.

CVS users may also want to read Documentation/gitcvs-migration.txt (man gitcvs-migration or git help cvs-migration if git is installed).

The user discussion and development of Git take place on the Git mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission and Documentation/CodingGuidelines).

Those wishing to help with error message, usage and informational message string translations (localization l10) should see po/README.md (a po file is a Portable Object file that holds the translations).

To subscribe to the list, send an email to git+subscribe@vger.kernel.org (see https://subspace.kernel.org/subscribing.html for details). The mailing list archives are available at https://lore.kernel.org/git/, https://marc.info/?l=git and other archival sites.

Issues which are security relevant should be disclosed privately to the Git Security mailing list git-security@googlegroups.com.

The maintainer frequently sends the "What's cooking" reports that list the current status of various development topics to the mailing list. The discussion following them give a good reference for project status, development direction and remaining tasks.

The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your mood):

  • random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
  • stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
  • "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
  • "goddamn idiotic truckload of sh*t": when it breaks
Description
No description provided
Readme 587 MiB
Languages
C 50.5%
Shell 38.7%
Perl 4.5%
Tcl 3.2%
Python 0.8%
Other 2.1%