Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git diff: is it possible to show ONLY changed lines

Tags:

git

git-diff

diff

I'm trying to get only new version of lines which have changed and not all the other info which git diff shows.

For:

git diff HEAD --no-ext-diff --unified=0 --exit-code -a --no-prefix

It shows:

diff --git file1 file2
index d9db605..a884b50 100644
--- file1
+++ file2
@@ -16 +16 @@ bla bla bla
-old text
+new text

what I want to see is only:

new text

Is it possible?

like image 393
Artem Avatar asked Aug 26 '14 04:08

Artem


People also ask

How do I see changes in git diff?

4 Diff Comparisons You Need to Know You can run the git diff HEAD command to compare the both staged and unstaged changes with your last commit. You can also run the git diff <branch_name1> <branch_name2> command to compare the changes from the first branch with changes from the second branch.

What does git diff show you?

The git diff command helps you see, compare, and understand changes in your project. You can use it in many different situations, e.g. to look at current changes in your working copy, past changes in commits, or even to compare branches.

What does ++ mean in git diff?

When viewing a combined diff, if the two files you're comparing have a line that's different from what they were merged into, you will see the ++ to represent: one line that was added does not appear in either file1 or file2.


7 Answers

Only added lines does not make sense in all cases. If you replaced some block of text and you happend to include a single line which was there before, git has to match and guess. - Usually the output of git diff could be used as input for patch afterwards and is therefore meaningful. Only the added lines are not precisely defined as git has to guess in some cases.

If you nevertheless want it, you cannot trust a leading + sign alone. Maybe filtering all the green line is better:

git diff --color=always|perl -wlne 'print $1 if /^\e\[32m\+\e\[m\e\[32m(.*)\e\[m$/'

for only deleted lines filter for all the red lines:

git diff --color=always|perl -wlne 'print $1 if /^\e\[31m-(.*)\e\[m$/'

to inspect the color codes in the output you could use:

git diff --color=always|ruby -wne 'p $_'
like image 168
michas Avatar answered Oct 18 '22 02:10

michas


If you specifically want only the new text part, then use the following:

git diff HEAD --no-ext-diff --unified=0 --exit-code -a --no-prefix | egrep "^\+"

This is basically your code, piped into the egrep command with a regex. The regex will filter only lines starting with a plus sign.

If you want to use this as an alias in scripting context, make sure to escape the escape char. Inside your ~/.gitconfig file, add:

[alias]
  diffaddedonly = !git diff HEAD --no-ext-diff --unified=0 --exit-code -a --no-prefix | egrep '^\\+'
like image 31
metacubed Avatar answered Oct 18 '22 03:10

metacubed


You can use:

git diff -U0 <commit-hash> | grep "^\+\""

This will give your output as "+new text"

like image 33
Srini Avatar answered Oct 18 '22 01:10

Srini


Here is an answer using grep. It retains the original red/green colors for readability. I provided a few variations in syntax:

git diff --color | grep --color=never $'^\e\[3[12]m'
git diff --color | grep --color=never $'^\033\[3[12]m'
git diff --color | grep --color=never -P '^\e\[3[12]m'
git diff --color | grep --color=never -P '^\033\[3[12]m'

Explanation:

  • git diff --color is needed to prevent git from disabling the color when it is piping.
  • grep --color=never prevents grep from highlighting the matched string (which removes the original color from the original command)
  • Match lines that start with red (\e[31m) or green (\e[32m) escape codes.
  • The $'...' (ANSI-C quoting syntax) or -P (perl syntax) is to let grep to interpret \e or \033 as an ESC character.
like image 30
wisbucky Avatar answered Oct 18 '22 01:10

wisbucky


If you want the process to be automatic, for a single file, you can use diff rather than git diff, doing :

diff --changed-group-format='%>' --unchanged-group-format='' <( git show HEAD:myfile.ext ) myfile.ext
  • <( ) makes diff use the result of git show HEAD:myfile.ext as first input
  • --changed-group-format='%>' tells diff to output added lines
  • --unchanged-group-format='' tells diff to output nothing for removed lines

For getting the info for a commit (not for the current worktree modifications), you can even do

diff --changed-group-format='%>' --unchanged-group-format='' <( git show _SHA_~:myfile.ext ) <( git show _SHA_:myfile.ext )

where _SHA_ is any reference to a commit (SHA, branch, tag, ...)

(For those who wonder why I needed this : I've got a "update.sql" file in which all SQL statements are put. So, on project update, I've got to find which lines have been added, to make Mysql execute them).

I found these diff options in this answer

like image 40
Pierre-Olivier Vares Avatar answered Oct 18 '22 03:10

Pierre-Olivier Vares


Unfortunately the color stuff isn't so portable to windows (with the commands supported by unxutils). However there is a solution to the +++ problem solved by using the color mode.

Additionally we probably don't want the leading character either. So lets use sed to get rid of it once we've matches with it:

git diff --no-ext-diff --unified=0 -a --no-prefix --output-indicator-new=% | sed -n "s/^%\(.*\)$/\1/p"

if you want deleted lines:

git diff --no-ext-diff --unified=0 -a --no-prefix --output-indicator-old=% | sed -n "s/^%\(.*\)$/\1/p"

By substituting % for + you don't have to worry about the header lines that start with +++ (b/c git doesn't use that prefix there... however that could change, this is still a porcelain command)

The prefix character must be ASCII (so no getting fancy with unicode). Given the vagaries of Windows/Linux/sed syntax. I think, the only ASCII chars that won't require escaping somewhere are: %,_~

Depending on your needs you may want to drop -a as binary files can make a mess of things.

--exit-code mentioned in another answer is a noop. By running thru a pipe, we only get the second exit code (tested on both Windows and Linux)

like image 21
DevNull Avatar answered Oct 18 '22 02:10

DevNull


A pragmatic approach: Restore the old version (take care not to overwrite your changes), and use good old diff.

like image 1
ynux Avatar answered Oct 18 '22 01:10

ynux