git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Jerry Zhang <jerry@skydio.com>,
	Git Mailing List <git@vger.kernel.org>,
	ross@skydio.com, abe@skydio.com, brian.kubisiask@skydio.com,
	Jerry Zhang <jerryxzha@googlemail.com>
Subject: Re: [PATCH 1/1] git-apply: Allow simultaneous --cached and --3way options
Date: Fri, 02 Apr 2021 21:26:00 -0700	[thread overview]
Message-ID: <xmqqy2e00zaf.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BGhvQF9k1Jw9NPbZWMkNSffqR777-4S-y-Sh=Etvw-SAA@mail.gmail.com> (Elijah Newren's message of "Fri, 2 Apr 2021 20:46:44 -0700")

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.



  reply	other threads:[~2021-04-03  4:28 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-03  1:34 [PATCH 0/1] " Jerry Zhang
2021-04-03  1:34 ` [PATCH 1/1] " Jerry Zhang
2021-04-03  3:46   ` Elijah Newren
2021-04-03  4:26     ` Junio C Hamano [this message]
2021-04-04  1:02       ` Junio C Hamano
2021-04-05 22:12         ` Jerry Zhang
2021-04-05 22:23           ` Junio C Hamano
2021-04-05 23:29             ` Jerry Zhang
2021-04-06  0:10               ` Junio C Hamano
2021-04-05 22:08     ` Jerry Zhang
2021-04-05 22:19   ` [PATCH V2] " Jerry Zhang
2021-04-05 22:46     ` Junio C Hamano
2021-04-06  2:52       ` Jerry Zhang
2021-04-06  5:52         ` Junio C Hamano
2021-04-06 21:56           ` Jerry Zhang
2021-04-07  2:25             ` Jerry Zhang
2021-04-06  2:49     ` [PATCH v3] git-apply: allow " Jerry Zhang
2021-04-07 18:03       ` [PATCH v4] " Jerry Zhang
2021-04-07 19:00         ` Junio C Hamano
2021-04-08  2:13         ` [PATCH v5] " Jerry Zhang
2021-04-08 13:33           ` Junio C Hamano
2021-04-12 15:45             ` Elijah Newren
2021-04-12 18:26               ` Junio C Hamano
2021-04-12 15:40           ` Elijah Newren
2021-04-12 18:27             ` Junio C Hamano
2021-04-03  3:04 ` [PATCH 0/1] git-apply: Allow " Elijah Newren
2021-04-05 22:05   ` Jerry Zhang
2021-04-03  5:24 ` Bagas Sanjaya
     [not found]   ` <CAMKO5CtiW84E4XjnPRf-yOPp+ua_u07LsAu=BB0YhmP3+3kYiw@mail.gmail.com>
2021-04-03  8:05     ` Bagas Sanjaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqy2e00zaf.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=abe@skydio.com \
    --cc=brian.kubisiask@skydio.com \
    --cc=git@vger.kernel.org \
    --cc=jerry@skydio.com \
    --cc=jerryxzha@googlemail.com \
    --cc=newren@gmail.com \
    --cc=ross@skydio.com \
    --subject='Re: [PATCH 1/1] git-apply: Allow simultaneous --cached and --3way options' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).