From: Jerry Zhang <jerry@skydio.com>
To: Elijah Newren <newren@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
Ross Yeager <ross@skydio.com>, Abraham Bachrach <abe@skydio.com>,
Jerry Zhang <jerryxzha@googlemail.com>,
Brian Kubisiak <brian.kubisiak@skydio.com>
Subject: Re: [PATCH 1/1] git-apply: Allow simultaneous --cached and --3way options
Date: Mon, 5 Apr 2021 15:08:01 -0700 [thread overview]
Message-ID: <CAMKO5Ct89R=Ls61H-q4ArhmWSokRQKS_uc93+=6_Gnxnjnk80A@mail.gmail.com> (raw)
In-Reply-To: <CABPp-BGhvQF9k1Jw9NPbZWMkNSffqR777-4S-y-Sh=Etvw-SAA@mail.gmail.com>
On Fri, Apr 2, 2021 at 8:46 PM Elijah Newren <newren@gmail.com> wrote:
>
> I'm not that familiar with apply.c, but let me attempt to take a look...
>
> On Fri, Apr 2, 2021 at 6:36 PM Jerry Zhang <jerry@skydio.com> wrote:
> >
> > Previously, --cached and --3way were not
> > allowed to be used together, since --3way
> > wrote conflict markers into the working tree.
> >
> > These changes change semantics so that if
> > these flags are given together and there is
> > a conflict, the conflict markers are added
> > directly to cache. If there is no conflict,
> > the patch is applied directly to cache as
> > expected.
> >
> > Signed-off-by: Jerry Zhang <jerry@skydio.com>
> > Signed-off-by: Jerry Zhang <jerryxzha@googlemail.com>
> > ---
> > Documentation/git-apply.txt | 4 +++-
> > apply.c | 13 +++++++------
> > 2 files changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
> > index 91d9a8601c..3dc0085066 100644
> > --- a/Documentation/git-apply.txt
> > +++ b/Documentation/git-apply.txt
> > @@ -89,7 +89,9 @@ OPTIONS
> > and we have those blobs available locally, possibly leaving the
> > conflict markers in the files in the working tree for the user to
> > resolve. This option implies the `--index` option, and is incompatible
> > - with the `--reject` and the `--cached` options.
> > + with the `--reject` option. When used with the --cached option, any
> > + conflict markers are added directly to the cache rather than the
> > + working tree.
> >
> > --build-fake-ancestor=<file>::
> > Newer 'git diff' output has embedded 'index information'
> > diff --git a/apply.c b/apply.c
> > index 6695a931e9..fc94ca0e99 100644
> > --- a/apply.c
> > +++ b/apply.c
> > @@ -133,8 +133,6 @@ int check_apply_state(struct apply_state *state, int force_apply)
> >
> > if (state->apply_with_reject && state->threeway)
> > return error(_("--reject and --3way cannot be used together."));
> > - if (state->cached && state->threeway)
> > - return error(_("--cached and --3way cannot be used together."));
> > if (state->threeway) {
> > if (is_not_gitdir)
> > return error(_("--3way outside a repository"));
> > @@ -4490,13 +4488,16 @@ static int create_file(struct apply_state *state, struct patch *patch)
> >
> > if (!mode)
> > mode = S_IFREG | 0644;
> > - if (create_one_file(state, path, mode, buf, size))
> > - return -1;
> > + if (!state->cached) {
>
> Why add this check? create_one_file() already has an early return if
> state->cached is true.
>
removed in latest patch
> > + if (create_one_file(state, path, mode, buf, size))
> > + return -1;
> > + }
> >
> > - if (patch->conflicted_threeway)
> > + if (patch->conflicted_threeway && !state->cached)
> > return add_conflicted_stages_file(state, patch);
> > - else if (state->update_index)
> > + else if (state->update_index) {
> > return add_index_file(state, path, mode, buf, size);
>
> So if something had conflicts, you ignore the various conflicted
> modes, and just add it to the index as it stands. What if it was
> deleted upstream and modified locally? Doesn't that just ignore the
> conflict, make it invisible to the user, and add the locally modified
> version? Similarly if it was renamed upstream and modified locally,
> doesn't that end up in both files being present? And if there's a
> directory/file conflict, due to the lack of ADD_CACHE_SKIP_DFCHECK (or
> whatever it's called), the add is just going to fail, but perhaps
> that's the most reasonable case as it'd print an error message and
> return -1, I think.
>
> Again, I didn't test any of this out and I'm not so familiar with this
> code, so I'm guessing at these scenarios. If I'm wrong about how this
> works, the commit message probably deserves an explanation about why
> they work, and we'd definitely need a few testcases for these types of
> scenarios. If I'm right, the current implementation is problematic at
> least if not the idea of using these options together.
Echoing my other reply, I think I will give up on the conflict markers and
just leave the files at the higher stages. I think that will address any
safety concerns since that's what --3way does without the cached
flag
next prev parent reply other threads:[~2021-04-05 22:08 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-03 1:34 [PATCH 0/1] git-apply: Allow simultaneous --cached and --3way options 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
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 [this message]
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='CAMKO5Ct89R=Ls61H-q4ArhmWSokRQKS_uc93+=6_Gnxnjnk80A@mail.gmail.com' \
--to=jerry@skydio.com \
--cc=abe@skydio.com \
--cc=brian.kubisiak@skydio.com \
--cc=git@vger.kernel.org \
--cc=jerryxzha@googlemail.com \
--cc=newren@gmail.com \
--cc=ross@skydio.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).