
From a useless Git Diff to a useful one - bitsweet
https://coderwall.com/p/crj69a
======
reidrac
The problem is not the diff but the "and besides that".

You should make two different commits, changing indentation and changing a
feature are different changes and should be tracked independently.

~~~
ranman
The real issue is that in practice it is often difficult to separate these two
changes. You may correct code in one place which requires correcting code
elsewhere in a cascading effect. If you limit your correction to just one area
(in a single commit) then you introduce the possibility of breaking the build.
The other issue is that if you fix all the whitespace stuff first you may find
the owners are not willing to pull in your commit for various reasons. I often
find in open source the smaller the change the more likely it is to be merged.
It's a complicated area and unfortunately often the "two different commits"
strategy doesn't encompass the full complexity.

Oh and another cool feature is worddiffs for when you're editing text.

~~~
r0muald
Whitespace changes in an open source project are the kind of thing that
depends on the code style enforced at the project level - certainly not
something you would submit as a newcomer. Do you happen to have an example of
what you're explaining here?

------
kyleslattery
Not sure if it does exactly the same thing, but on GitHub, if you add ?w=1 to
the end of a diff URL, it'll show it with whitespace ignored.

------
Groxx
My personal favorite: --patience

It tends to produce more "this looks like what I did" diffs, with code at
least.

------
SomeCallMeTim
Or use a diff tool that can do this automatically..? [1] Diff without the
ability to edit the changes you see is only about 10% as useful as the ability
to edit those diffs inline, change how it's decided to compare the two (or
three) files (match THIS line with THIS OTHER line...), or trivially revert
the changes a line at a time. [2]

I hop back and forth between GUI-based editors and the command line. Some
things are just better in a GUI, and diff is one of those things--especially
any nontrivial diff.

[1] [http://www.scootersoftware.com/](http://www.scootersoftware.com/)

[2] I'm sure you can do this in vi and/or emacs as well. I leave how to do
that as an exercise to the reader.

~~~
to3m
Well I don't disagree, even if everybody else does. I've long been a user of
Araxis Merge, which is not only visual, but also lets you edit the diffs as
you go, which comes in super handy for all the reasons that you state.

I didn't realise how spoiled I was until I started using git, and found the
hard way how limiting the text diff format can be. Column-oriented changes in
particular are very difficult to figure out, and even for more readable sets
of changes I always found it a bit hard to get a rough idea of how spread out
or clustered together the changes are. git gui and SourceTree try their best
to help, but ultimately they're just displaying a prettified version of the
same sometimes-unhelpful view of things.

On the other hand, if you're making small changes to a lot of files, a text
diff is just the thing. It would be hyperbole to state that there's nothing
worse than telling Araxis Merge to do a folder compare and find out that
1,000+ files have had 1 line changed in them - but it _is_ rather annoying,
and very time-consuming to investigate thoroughly. You need a text diff for
that sort of thing.

But I still always reach for Araxis first...

~~~
SomeCallMeTim
As I said, I hop back and forth between GUI and command line; I haven't
personally needed to deal with a folder diff with 1000+ files with one line
changed each, but if I did, command line seems like a reasonable option.

Beyond Compare (linked above) lets you set patterns to ignore, which has been
incredibly useful for when an autogenerated time/date stamp is changed in
1000+ files; I can say "ignore that change; tell me what changed that DOESN'T
match the pattern".

You can do the same thing with grep on the command line of course. But then
you lose out on all the GUI awesomeness.

I've used Araxis, and it's Even More Awesome, but 5x the cost (last I checked)
as Beyond Compare, and I didn't think it was 5x as awesome. BC has gotten much
cooler since then too (with comparison plug-ins, and bitmap compare -- let's
see diff compare two bitmaps and tell me which pixels have changed! -- and DOC
file compare, and normalized XML file compare, and so on ;).

------
jordigh
On Mercurial, all of those options are just "hg diff -w".

You can also ignore whitespace when picking commits apart with hg record (akin
to git add -p, I think).

------
ranman
Also everyone should be using tig:
[http://jonas.nitro.dk/tig/](http://jonas.nitro.dk/tig/)

------
philsnow
I'd really like a diff option that ignores changes that don't alter the AST.

That's pretty outside the scope of git diff or gnu diff, though.

------
civilian
An alias for bash

    
    
      gitdiff() {
            git diff --patience --ignore-space-at-eol -b -w --ignore-blank-lines $1
      }

~~~
ominous_prime
why make a bash _function_ , when git has it's own alias feature?

Also, you're only accepting one argument, where there could be many depending
on your refspec and path.

~~~
Cyranix
For those wondering: in ~/.gitconfig or similar,

    
    
      [alias]
        df = diff --patience --ignore-space-at-eol -b -w --ignore-blank-lines

