Silly 'git am' UI issue

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