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

From: Junio C Hamano <junkio@cox.net>
Date: Mar 14, 2007, 01:31 UTC
Message-ID: <7vveh4hapk.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0703131757080.9690@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 9 quoted lines

> 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)" t/t0020-crlf.sh: differs=`git diff-index --cached HEAD` && t/t0020-crlf.sh: differs=`git diff-index --cached HEAD` && t/t0020-crlf.sh: differs=`git diff-index --cached HEAD` && t/t0020-crlf.sh: differs=`git diff-index --cached HEAD` &&

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.