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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 3, 2021, 04:26 UTC
Message-ID: <xmqqy2e00zaf.fsf@gitster.g>
In-Reply-To: <CABPp-BGhvQF9k1Jw9NPbZWMkNSffqR777-4S-y-Sh=Etvw-SAA@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

> I'm not that familiar with apply.c, but let me attempt to take a look...

I am (well, at least I was the one who invented 3way and added the "index" line to the diff output format) ;-)

> scenarios.  If I'm right, the current implementation is problematic at
> least if not the idea of using these options together.

Yes, the conflicted case cannot sanely be handled _without_ leaving higher stage entries in the index, and that is exactly why I made it incompatible with the "--cached" mode.

It might be OK to only allow the combination when everything auto resolves cleanly and fail the operation without touching either the index or the working tree. Pretending there was no delete/modify conflicts or adding contents with unresolved conflicts as if nothing bad happened as stage 0 entries would never be acceptable.

Perhaps

 * Error out if the index does not match HEAD.

 * Try applying to the contents in the index.  If there are any
   structural conflicts, leave these paths at higher stage and do
   not touch their contents.

 * For paths without structural conflict but need content merges,
   attempt ll-merge of the contents.  If autoresolves cleanly,
   register the result at stage 0.  Otherwise, discard the failed
   conflicted merge, and leave stages 1, 2 and 3 as they are.

 * Exit with status 0 if and only if everything has resolved
   cleanly.  Otherwise, exit with non-zero status.

would be the minimally-acceptably-safe behaviour.