Re: [PATCH] Allow git-diff exit with codes similar to diff(1)

["Alex Riesen" <raa.lkml@gmail.com>]

On 3/14/07, Junio C Hamano <junkio@cox.net> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > On Wed, 14 Mar 2007, Alex Riesen wrote:
> >>
> >> This introduces a new command-line option: --exit-code. The diff
> >> programs will return 1 for differences, return 0 for equality, and
> >> something else for errors.
> >
> > I don't think you should need a new command-line option.
> >
> > Is there any reason to not just do this unconditionally?
>
> Exiting with 0 for no-change, 1 for has-change and other value
> for error is something that falls into the
>
>     "I wish if we did it from day one, but now many people's
>     scripts depend on the behaviour, and heck we ourselves say
>     that the right way to see if there is difference is to check
>     if the output is an empty string (look at a few scripts of
>     our own), so it would be a huge backward compatibility
>     hassle"
>
> category.
>
> e.g.
>
> git-am.sh:      files=$(git-diff-index --cached --name-only HEAD) || exit
> git-am.sh:      changed="$(git-diff-index --cached --name-only HEAD)"

Isn't this crazy? Get the information and never really use it?
The second one does not check for errors, BTW. Will
break if someone sends enough files in one commit to go past
local limit on shell variable size (or the local limit on process size,
which is much worse situation: everything gets swapped out).

> And I expect people's scripts are modelled after how git's
> scripts do things --- if they were half competent, they'd know
> that would be the way to make sure their scripts would be
> compatible with future plumbing changes.

That is expert level. The half competents are used to diff(1).