4

I am trying to perform Git diff in two branches with the same file. I want to get the difference of two files.

  • If there is a fatal error
  • If there is a difference/ not matched
  • If there is NO difference/ matched

I tried saving the command in a variable to get the result. Example: GIT_DIFF=$(git diff RB_202005:/test.txt RB_202006:/test.txt) and then printing the variable (Example: echo $GIT_DIFF) but nothing is being returned.

Improve this question
7
  • 1
    Maybe try capturing stderr also, Commented May 12, 2020 at 2:09
  • Hello. Can you give an example of the usage of stderr? Thank you very much. Commented May 12, 2020 at 2:13
  • 1
    here 2>&1 use that and see if it solve your issue. Commented May 12, 2020 at 2:17
  • Is this correct? GIT_DIFF=$(git diff RB_202005:/test.txt RB_202006:/test.txt 2>&1) Another question, how should I print the stderr? Commented May 12, 2020 at 4:28
  • 1
    If those two files match, git diff prints nothing, so the variable is set to the empty string and printing it prints nothing. Only if the two files differ, or there is some error in computing the diff, will the variable be set to something other than the empty string. Commented May 12, 2020 at 5:57

2 Answers 2

Reset to default
4

Since you are only interested in the cases "no diff", "diff", "error", I would run a 

git diff --exit-code --quiet .....

--exit-code sets the exit code in the way the normal diff would do.

--quiet suppresses the output.

If the exit code is 0, you don't have differences.

If the exit code is 1, you have differences.

If the exit code is 2 or 128, you have fatal errors.

UPDATED As the OP pointed out in the comment, git-diff --exit-code produces status code 128, if the file to be compared does not exist. According to the man-page, it should produce the same exit code as the standard diff, which would be 2. Hence it is best to treat any exit code larger than 1 as standard error. This would also catch the case that git itself is not found (in which case the shell would likely report exit code 127).

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Yes, but be careful and save it to a different variable immediately after running git diff, because every command afterwards (including, say, any echo) will overwrite $?`.
In my case, Exit Code 128 is when there are fatal errors. Thank you very much.
@Roan: Indeed, I could reproduce it. To me it seems to be a bug, because it contradicts the description given in the man-page. I suggest that you catch any exit code larger than 1 as fatal error, in case the git developers fix this one day.
Just git diff --quiet works, because it implies --exit-code.
@Roan : Exit code 128 really looks like a bug. A process is not supposed to set this explicitly. "Normal" exit codes are below 126 - see here.
1

This would not always work with the new (Git 2.30, Q1 2021) git diff -I, should you want to ignore a diff pattern.

"git diff -I<pattern> -exit-code(man)" should exit with 0 status when all the changes match the ignored pattern, but it didn't.

See commit 50f0439 (16 Dec 2020) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit 59fcf74, 18 Dec 2020)

diff: correct interaction between --exit-code and -I<pattern>

Just like "git diff -w --exit-code"(man) should exit with 0 when ignoring whitespace differences results in no changes shown, if ignoring certain changes with "git diff -I<pattern> --exit-code(man)" result in an empty patch, we should exit with 0.

The test suite did not cover the interaction between "--exit-code" and "-w"; add one while adding a new test for "--exit-code" + "-I".

And with Git 2.46 (Q3 2024), batch 4, the "--exit-code" option of "git diff"(man) command learned to work with the --ext-diff option.

That means you can combine git diff --exit-code --quiet with an external driver, which could return error codes similar to the standard diff, instead of the default git diff error codes.

See commit 11be65c, commit 7b30c3a (05 May 2024) by René Scharfe (rscharfe).
(Merged by Junio C Hamano -- gitster -- in commit 068df18, 15 May 2024)

diff: fix --exit-code with external diff

But was reverted with commit e37423f: per original author's request to come up with a better strategy.

With Git 2.46 (Q3 2024), batch 15, "git diff --exit-code --ext-diff``"(man) learned to take the exit status of the external diff driver into account when deciding the exit status of the overall git diff(man) invocation when configured to do so.

See commit d7b97b7, commit 54443bb, commit 33be6cf (09 Jun 2024) by René Scharfe (rscharfe).
(Merged by Junio C Hamano -- gitster -- in commit 8ba7dbd, 20 Jun 2024)

diff: let external diffs report that changes are uninteresting

Suggested-by: Phillip Wood
Signed-off-by: René Scharfe

The options --exit-code and --quiet instruct git diff(man) 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..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(man) 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 11be65c ("diff: fix --exit-code with external diff", 2024-05-05, Git v2.46.0 -- merge listed in batch #4) 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(man) 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(man) to the external diff can cause unnecessary confusion.

git config now includes in its man page:

diff.trustExitCode

If this boolean value is set to true then the diff.external command is expected to return exit code 0 if it considers the input files to be equal or 1 if it considers them to be different, like diff(1).

If it is set to false, which is the default, then the command is expected to return exit code 0 regardless of equality. Any other exit code causes Git to report a fatal error.

git config now includes in its man page:

diff.<driver>.trustExitCode

If this boolean value is set to true then the diff.<driver>.command command is expected to return exit code 0 if it considers the input files to be equal or 1 if it considers them to be different, like diff(1).

If it is set to false, which is the default, then the command is expected to return exit code 0 regardless of equality. Any other exit code causes Git to report a fatal error.

diff-options now includes in its man page:

Disables execution of external diff helpers whose exit code is not trusted, i.e. their respective configuration option diff.trustExitCode or diff.<driver>.trustExitCode or environment variable GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE is false.

git now includes in its man page:

GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE

If this Boolean environment variable is set to true then the GIT_EXTERNAL_DIFF command is expected to return exit code 0 if it considers the input files to be equal or 1 if it considers them to be different, like diff(1).

If it is set to false, which is the default, then the command is expected to return exit code 0 regardless of equality. Any other exit code causes Git to report a fatal error.

gitattributes now includes in its man page:

If the program is able to ignore certain changes (similar to git diff --ignore-space-change), then also set the option trustExitCode to true.

It is then expected to return exit code 1 if it finds significant changes and 0 if it doesn't.

In your case, I have tested:

#!/bin/bash export GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE=true branch1="RB_202005" branch2="RB_202006" file_path="/test.txt" git config diff.external 'myCustomDiffTool' git config diff.myCustomDiffTool.trustExitCode true diff_output=$(git diff --exit-code --ext-diff $branch1:$file_path $branch2:$file_path 2>&1) exit_code=$? case $exit_code in 0) echo "No differences found." ;; 1) echo "Differences found:" echo "$diff_output" ;; *) echo "Fatal error encountered:" echo "$diff_output" exit 1 ;; esac git config --unset diff.external git config --unset diff.myCustomDiffTool.trustExitCode
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.