Re: [PATCH V2] git-apply: Allow simultaneous --cached and --3way options

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 6, 2021, 05:52 UTC
Message-ID: <xmqqh7kk2c49.fsf@gitster.g>
In-Reply-To: <CAMKO5CuLpa9Sn_oXMpgP6oGE9NFA8aLeTfeyaW6TOTErE0KgEg@mail.gmail.com>

Jerry Zhang <jerry@skydio.com> writes:

> Thanks for the comments! I've updated v3 with the changes. Let me know
> if you have any
> more thoughts on whether to block / warn the user before clobbering their cache.

Please do not top-post on this list.

I've already said that I think we should ensure the index is clean by default, because, unlike the case where the application is done on the working tree files, the use of "--cached" is a sign that the next step is likely to write a tree out. As I've already said so in earlier reviews, there is nothing more from me to add on that issue.

Show 14 quoted lines

>> Give an order to the codebase to "be like so".  Here is my attempt.
>>
>>     Teach "git apply" to accept "--cached" and "--3way" at the same
>>     time.  Only when all changes to all paths involved in the
>>     application auto-resolve cleanly, the result is placed in the
>>     index at stage #0 and the command exits with 0 status.  If there
>>     is any path whose conflict cannot be cleanly auto-resolved, the
>>     original contents from common ancestor (stage #1), our version
>>     (stage #2) and the contents from the patch (stage #3) for the
>>     conflicted paths are left at separate stages without any attempt
>>     to resolve the conflict at the content level, and the command
>>     exists with non-zero status, because there is no place (like the
>>     working tree files) to leave a half-resolved conflicted merge
>>     result to ask the end-user to resolve.

I wrote the above as an example to illustrate the tone and the level of details expected in our proposed commit log message. The behaviour it describes may not necessarily match what you have implemented in the patch.

For example, imagine that we are applying a patch for two paths, where one auto-resolves cleanly and the other does not. The above description expects both paths will leave the higher stages (instead of recording the auto-resolved path at stage #0, and leaving the other path that cannot be auto-resolved at higher stages) and the command exits with non-zero status, which may not be what you implemented. As an illustration, I didn't necessarily mean such an all-or-none behaviour wrt resolving should be what we implement---I do not want to choose, as this is your itch and I want _you_ with the itch to think long and hard before deciding what the best design for end-users would be, and present it as a proposed solution. An obvious alternative is to record auto-resolved paths at stage #0 and leave only the paths for which auto-resolution failed in conflicted state.

Thanks.