On Thu, Oct 18, 2018 at 03:12:09PM -0500, Mahmoud Al-Qudsi wrote:
> Hello again all,
> 
> I think I've previously broached this subject before, but I think I perhaps
> wasn't clear enough about what I was trying to do or why I feel that git is at
> fault here.
> 
> (I'm running git 2.19.1)
> 
> Starting with a fully-committed, not-dirty codebase, I open(ed) a poorly
> formatted, mixed-whitespace file (that I absolutely did not author!) under
> version control and make some very localized changes. My editor, being very
> smart and helpful, fixes up the line ending on save, and I exit.
> 
> At this point, my source file contains a) deliberate changes I want, and b)
> whitespace changes I wish I could commit but that should not be a part of my
> patch.
> 
> Shouldn't the following workflow be supported:
> 
> ~> git diff -w > foo.diff
> ~> git reset --hard
> ~> git apply [--ignore-whitespace] < foo.diff

In general, git diff -w doesn't produce a patch that can be applied.
That's because it ignores all whitespace changes in a particular way.
The diff output is rendered as if the whitespace in the lines were
written as it is in the postimage (the changed file), not the preimage
(the original file).

This is useful because usually if you're, say, indenting a block of
code, you want to see the output properly indented with the new lines of
code (say, the loop or conditional) you wrote around it.  And since this
feature is designed for visual inspection, it makes sense to do it this
way.  However, it essentially means that your changes can't, in general,
be applied.

There are, of course, situations in which this might have worked in the
past, and it may indeed work for some situations still, but it won't in
the general case.  git apply --ignore-whitespace only modifies context
lines, so it doesn't affect the actual content lines in the diff.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204