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

[Junio C Hamano <junkio@cox.net>]

"Alex Riesen" <raa.lkml@gmail.com> writes:

> Challenging... Now, if someone just told me where to look for
> differences in diff-tree case...

As the resident git-diff expert I might hack on this myself as
the --quiet options are useful, and --exit-code comes almost
free when you properly do --quiet that implies --quick.

>> A slight tangent, but what Linus recalled he thought he did but
>> he didn't is related to the parts you touched in diff-tree
>> above.  Because of the interaction with diffcore, these changes
>> should not be used for the purpose of -exit-code, but catching
>> the tree level change in the above places and leaving early
>> would be the right thing to do for comparing the whole tree for
>> the purpose of simplifying the parents.  Tomorrow will be my git
>> day so I might whip up a patch to speed that up.
>
> Can it eventually be wired to "-s" (DIFF_FORMAT_NO_OUTPUT)?

I do not think so.  When we run diff internally to pick the set
of paths (i.e. run diffcore and check contents of diff_queue,
just like you did for diff-index/diff-files), we internally use
NO_OUTPUT.  See merge-recursive.c for an example.

>> >       diffcore_std(&revs->diffopt);
>> > +     ret = revs->diffopt.diff_exit_code && diff_queued_diff.nr ? 1: 0;
>> >       diff_flush(&revs->diffopt);
>> >       return ret;
>> >  }
>>
>> This side looks correct, as you are counting queued_diff.nr after
>> letting diffcore_std() to filter the results.
>
> And it will continue to work if the diffing is left early because of
> no output needed. Err, will it?

To implement --quick correctly, you need to know when it is safe
to leave early.  Presence of -S (pickaxe) would most likely mean
you shouldn't leave early.