Ok, so I'm "intellectually challenged" sometimes.
I tend to apply patches with
$ git am -s --whitespace=fix <filename>
and just a moment ago I had a senior moment, and instead did
$ git am -s --whitespace <filename>
and then wondered what the heck was wrong with my machine for being so slow.
I ^C'd it, and tried again, because I really am not a smart man. On
the *third* try, it finally dawned on me what a maroon I was.
The problem is obvious when I list those "right way" and "wrong way"
next to each other, but even then the *behavior* is most certainly not
obvious.
And this is really just a problem with "git am" (and possibly "git
rebase"), because they know that the "whitespace" option needs a
value, but they don't actually _check_ that value. They just know it's
a "passthru" argument to "git apply" (and "git am" in the case of
rebase).
So what happens is that "git am" decides that <filename> is the
argument to the "--whitespace" option, then doesn't see an argument at
all, and expects the input from stdin. So it "hangs", waiting for
input. No error messages, no nothing.
If you actually do the same thing to "git apply", you don't see the
problem, and it clarifies things:
$ git apply --whitespace <filename>
error: unrecognized whitespace option '<filename>'
and it's all very obvious what is going on.
But "git am" never even gets to that stage, because it is busy waiting
for input that will never come from the terminally confused person
sitting in front of the keyboard.
I don't think this is a bug, exactly, but it did make me go "Whaa?".
But that may be because my other neuron hasn't had enough coffee yet.
Linus
