Re: [PATCH 2/2] builtin/apply.c: report error on failure to recognize input
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 5, 2011, 19:27 UTC
- Message-ID
- <7vzkf6lsyx.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <1322944550-27344-2-git-send-email-drafnel@gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
Show 23 quoted lines
> When git apply is passed something that is not a patch, it does not produce > an error message or exit with a non-zero status if it was not actually > "applying" the patch i.e. --check or --numstat etc were supplied on the > command line. > > Fix this by producing an error when apply fails to find any hunks whatsoever > while parsing the patch. > > This will cause some of the output formats (--numstat, --diffstat, etc) to > produce an error when they formerly would have reported zero changes and > exited successfully. That seems like the correct behavior though. Failure > to recognize the input as a patch should be an error. > > Plus, add a test. > > Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> > Signed-off-by: Brandon Casey <drafnel@gmail.com> > --- > > Initially, I was reluctant to change the error message, thinking that > error messages for plumbing commands were not supposed to change. But I > think I was wrong in that thought, so I changed the error message so it > was a more descriptive "unrecognized input".
I am still reluctant to see
$ git apply </dev/null
error: unrecognized inputinstead of "error: No changes", though.
"git apply --check" is about asking "do you see anything offending in the diff?" and it is not "git apply --dry-run" that asks "do you promise if I feed this for real to you you will apply it without complaint?".
I am slightly in favor of answering "well you do not have a diff to begin with, which in itself is suspicious" to "do you see anything offending?" question, but I have to admit that it is an equally valid answer to say "no, there is nothing offending in the diff.", which is what we do with the current code.
So, I dunno.