git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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 input
instead 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.
Previous: Brandon CaseyNext: Brandon Casey
Message 5 of 6 in “t/t4131-apply-fake-ancestor.sh: fix broken test”
  1. 1/2 t/t4131-apply-fake-ancestor.sh: fix broken testBrandon Casey, Dec 3, 2011
  2. 2/2 builtin/apply.c: report error on failure to recognize inputBrandon Casey, Dec 3, 2011
  3. Artem BityutskiyDec 4, 2011
  4. Brandon CaseyDec 4, 2011
  5. Junio C HamanoDec 5, 2011
  6. Brandon CaseyDec 5, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.