Re: [PATCH v2 2/3] builtin: introduce diff-pairs command

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 19, 2025, 23:47 UTC
Message-ID: <xmqqwmdlebua.fsf@gitster.g>
In-Reply-To: <xmqq1pvtfrq0.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 18 quoted lines

>> Regarding pathspec support, being that git-diff-pairs(1) operates solely
>> on the provided set of file pairs produced via some other Git operation,
>> I don't think further limiting would provide much additional value
>> either. If we do want this though, I think support could be added in the
>> future.
>
> Another consideration is which side of the pipeline should take the
> responsibility to invoke the diffcore machinery.  We certainly could
> make it the job for the upstream/frontend, in which case diff-pairs
> does not have to call into diffcore-rename, BUT it also means the
> downstream/backend needs to be able to parse two paths (renamed from
> and renamed to).  Or we could make it the job for the downstream,
> and forbid the upstream/frontend from feeding renamed pairs (i.e.
> any input with status letter R or C are invalid), in which case
> diff-pairs can choose to invoke rename detection or not by paying
> attention to the -M option and invoking diffcore_rename() itself
> (which should be at no-cost from coding point of view, as it should
> be just the matter of calling diffcore_std()).

Sorry, but I hit <SEND> too early before finishing the most important part. We can move the features between upstream frontends and downstream diff-pairs. Depending on our goals, the best division of labor would be different. If we want to make it easy for people to write their custom frontends, for example, it might make sense to allow them to be as stupid and simple as possible and make all the heavy lifting the responsibility of the diff-pairs backend, which is the shared resource these frontends share and rely on (so that they have incentive to help us make sure diff-pairs will stay correct and performant). If on the other hand we want to allow people to do fancy processing in their custom frontends, maybe keeping diff-pairs as stupid and transparent would be a better option to give the people who write upstream/frontends more predictable behaviour.

Where to do the pathspec limiting is one of these things. You could make it responsibility for the frontends if we assume that frontends must do their own limiting. Or you could make it an optional feature of the backends, so that frontends that does not do its own limiting can ask diff-pairs to limit. Which side to burden more really depends on whose job we are trying to make it easier.

Thanks.