On 3/14/07, Junio C Hamano <junkio@xxxxxxx> wrote:
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html