From: Junio C Hamano <gitster@pobox.com>
To: Jerry Zhang <jerry@skydio.com>
Cc: Elijah Newren <newren@gmail.com>,
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, 05 Apr 2021 15:23:36 -0700 [thread overview]
Message-ID: <xmqqy2dw4bh3.fsf@gitster.g> (raw)
In-Reply-To: <CAMKO5CtCk_sJsFFiKKFR1wCSyY226CbxPtN6=p6JRzocSuv8jQ@mail.gmail.com> (Jerry Zhang's message of "Mon, 5 Apr 2021 15:12:43 -0700")
Jerry Zhang <jerry@skydio.com> writes:
> I can see what you mean about the user safety issue. However,
> my specific use case (see cover letter) involves an index that does not
> match HEAD, and wouldn't be possible at all if we forced the index to
> match HEAD. Furthermore git-apply --cached even without --3way
> doesn't force the index to match HEAD either, so why force it now?
Primarily because we tend to be extra careful before mergy operation
than any other operation. Especially without --3way, apply (with or
without --cached/--index) is extra careful to make itself all-or-none
operation to be safe, so that there is no mixed mess that requires
manual intervention (which would further increase the risk of mistakes).
It is OK to introduce a new option to allow a dirty index, and your
tool can pass that option when it calls "apply --cached --3way", but
it would be safe to require a clean index (it does not matter how
dirty the working tree is ;-) by default.
next prev parent reply other threads:[~2021-04-05 22:23 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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy2dw4bh3.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=abe@skydio.com \
--cc=brian.kubisiak@skydio.com \
--cc=git@vger.kernel.org \
--cc=jerry@skydio.com \
--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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.