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

Re: bug & patch: exit codes from internal commands are handled incorrectly

From
Kenneth Lorber <keni@his.com>
Date
Feb 1, 2015, 22:32 UTC
Message-ID
<4B764581-0053-467C-93B5-C238EF5AE112@his.com>
In-Reply-To
<xmqqegrw7omv.fsf@gitster.dls.corp.google.com>
On Dec 18, 2014, at 2:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> Kenneth Lorber <keni@his.com> writes:
> 
>>> Bug: exit codes from (at least) internal commands are handled incorrectly.
>>> E.g. git-merge-file, docs say:
>>>       The exit value of this program is negative on error, and the number of
>>>       conflicts otherwise. If the merge was clean, the exit value is 0.
>>> But only 8 bits get carried through exit, so 256 conflicts gives
>>> exit(0), which means the merge was clean.
> 
> Wouldn't any cmd_foo() that returns negative to main() be buggy?
Yes.
> 
> Your change sweeps such problems under the rug, which is not a
> healthy thing to do.
Agreed.  (See below.)
Show 7 quoted lines
> 
> Expecting that the exit code can signal small positive integers and
> other generic kinds of failures is a losing proposition.  I think it
> is a better fix to update cmd_merge_file() to return 1 (when ret is
> positive), 0 (when ret is zero) or 128 (when ret is negative), or
> something simple like that, and update the documentation to match
> that, without touching git.c::main().
The new patch uses 0, 1, and 2 to match diff(1).
Show 30 quoted lines
> Among the in-tree users, I notice git-cvsserver.perl is already
> using the command incorrectly.  It does this:
> 
>            my $return = system("git", "merge-file", $file_local, $file_old, $file_new);
>            $return >>= 8;
> 
>            cleanupTmpDir();
> 
>            if ( $return == 0 )
>            {
>                $log->info("Merged successfully");
>                ...
>            }
>            elsif ( $return == 1 )
>            {
>                $log->info("Merged with conflicts");
>                ...
>            }
>            else
>            {
>                $log->warn("Merge failed");
>                next;
>            }
> 
> which assumes $return == 1 is special "half-good", which is not
> consistent with the documented interface.  It will incorrectly
> say "Merge failed" when there are two or more conflicts.
> 
> And with such a "1 or 0 or -1" change, you will fix that caller as
> well ;-)
I'll call that a win.
The attached patch covers the following:
- fixes all places where "make test" attempts to call exit() with a value <0 or >255
- changes git-merge-file.txt to reflect the change in exit codes
- fixes the exit codes for merge-file
- adds a warning (which should probably be changed to something clearer) if git.c:run_builtin() is going to cause an out-of-bounds exit
- fixes a typo in t7007-show.sh
- replaces return(0) with exit(0) in test-parse-options.c
The diff is cut against 15598cf41beed0d86cd2ac443e0f69c5a3b40321 (2.3.0-rc2)

Thanks, Keni

Previous: Kenneth LorberNext: Kenneth Lorber
Message 6 of 8 in “bug & patch: exit codes from internal commands are handled incorrectly”
  1. Kenneth LorberDec 16, 2014
  2. Kenneth LorberDec 18, 2014
  3. Torsten BögershausenDec 18, 2014
  4. Junio C HamanoDec 18, 2014
  5. Kenneth LorberDec 20, 2014
  6. Kenneth LorberFeb 1, 2015
  7. Kenneth LorberApr 1, 2015
  8. Junio C HamanoApr 1, 2015

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.