crj69a
Last Updated: February 25, 2016
·
46.41K
· dcsg
Profile photo 2014 web

From a useless Git Diff to a useful one

Imagine you have a file with 500 lines of code and you changed the indentation from tabs to spaces in more than 200 lines and besides that you changed the feature. Doing a normal git diff it will be useless because you will get a lot of diffs from the indentation changes.

But there is a way to make it useful, you just need to add some options to the git diff command and you are done:

Git version <= 1.8.3.4:
git diff --ignore-space-at-eol -b -w [commit] ...

Git version >= 1.8.4:
git diff --ignore-space-at-eol -b -w --ignore-blank-lines [commit] ...

See the options definition below:

--ignore-space-at-eol
Ignore changes in whitespace at EOL.

-b
--ignore-space-change
Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent.

-w
--ignore-all-space
Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none.

[git version 1.8.4+]--ignore-blank-lines
Ignore changes whose lines are all blank.

Say Thanks
Respond

11 Responses
Add your response

10235
C9e9e78b72d829bc4052f361eaf38254

Great tip! Although --ignore-blank-lines throws an error and I can't find it in the git spec?

error: invalid option: --ignore-blank-lines

Edit: It appears my git version is not up to date! (also just seen @danielcsgomes reply!)

over 1 year ago ·
10236
Profile photo 2014 web

The --ignore-blank-lines option is only available on Git version 1.8.4.

over 1 year ago ·
10440
986d255e94481d2249bae7911e7845e8

Every time you commit trailing spaces a panda dies. =(

over 1 year ago ·
10441
202ca7b4bfb76a9cc64da1b60a076dc5 normal

Is -w a particularly good idea? Wouldn't it silently treat doSomething(withThis) and do Something(with This) as equivalent?

over 1 year ago ·
10442
9177b14b30f517bbfd8061ee7d4dc578

I don't think I'd use this approach with python code...

over 1 year ago ·
10443
Db57bc42e6fbc602fc94df4a783200a0

This is wrong! if you ever, EVER, change indentation or trim a file, it should be ALWAYS on a separate commit.

  1. change ONLY white space. (stash anything else)
  2. run a diff with -b (or add all those fancy options) and see if it shows no changes.
  3. commit with comment "whitespace"
  4. push.
  5. continue with your work.

(edit: this was a numbered list, but the site changed it to bullet points.... )

over 1 year ago ·
10451
Profile photo 2014 web

@gcb this pro-tip is just about the git diff, not a strategy on how to commit/push this kind of situation. If that was the case the best approach IMO is the one you mentioned ;)

over 1 year ago ·
10452
Profile photo 2014 web

@alecb I guess it will depend on your purpose and situation and of course this is not a straight command, you should mix the options depending on your needs!

over 1 year ago ·
10454
10e57f7b8ddac1b80edf48e6afba391c

@alecb - untested, but I would think not. It ignores the diff between "test 123" and "test 123". But not the diff of "test123" and "test 123".

@gcb - of course. But say you want to compare the diff of two tags, or like many people you work with people who "don't get it".

over 1 year ago ·
10455
202ca7b4bfb76a9cc64da1b60a076dc5 normal

@joshribakoff Tested it, and it seems to do just that:

$ git diff
diff --git a/file b/file
index 5271a52..f5ac887 100644
--- a/file
+++ b/file
@@ -1 +1 @@
-test123
+test 123
(END)

$ git diff -w
(END)
over 1 year ago ·
18064
None

The options do not make sense to me:

  • -b is synonymous to --ignore-space-change
  • -w is synonymous to --ignore-all-space

If I understand the official documentation at http://git-scm.com/docs/git-diff correctly, -b should be a superset of --ignore-space-at-eol and -w in turn is a superset of -b. In that case, the command git diff --ignore-space-at-eol -b -w [commit] ... would be equivalent to simply git diff -w [commit] .... And I agree with @alecb that -w is a bad idea. Also untested, but I do understand the documentation such that it would regard "test123" and "test 123" as equivalent.

over 1 year ago ·
Filed Under