On Wed, Jul 01, 2026 at 03:06:52PM -0700, Junio C Hamano wrote:

quoted

One of the patches is rather long because we have many cases in which
we've hard-coded exit code 129 into our tests.  However, the changes
there should not be complex, only somewhat tedious to review.

It is borderline for "yes, we all know it is obvious that things
should have worked this way from day one, we regret that it is not
the case, but it has been working differently and users' scripts all
have been working with the current behaviour, and it is likely that
they will all break".

Two big things that make it much less likely, saving grace, are that
this is only about "--help" (which is unlikely to be a part of
end-user script), and this makes the invocation succeed (if we were
changing from exit 0 to exit 129, we would be breaking tons more).

My big concern is a script accidentally continuing when fed "--help" and
generating nonsense. But I think the eval magic explained in patch 3
makes that unlikely (any such caller was already kind-of broken).

The other issue I raised in the earlier round is that a script like:

  cat >git-foo <<\EOF
  #!/bin/sh
  git log --my-options "$@" >output || exit 1
  do_something <output
  EOF

when invoked as "git foo --help" will now call do_something with
nonsense input, rather than exiting from the "error" returned by
git-log. This only affects hacky little scripts like this that are not
otherwise parsing their own options, but sometimes those are the most
common. ;)

I'm not convinced there will be much fallout, but it is possible.

-Peff