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

From: Junio C Hamano <junkio@cox.net>
Date: Mar 14, 2007, 09:04 UTC
Message-ID: <7v6494dwms.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <81b0412b0703140128y46ff6bb6m503eeae00c043ddf@mail.gmail.com>

"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.

Show 10 quoted lines

>> 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.

Show 11 quoted lines

>> >       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.