Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Raymond E. Pasco" <ray@ameretat.dev>
Cc: <git@vger.kernel.org>, "Phillip Wood" <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH v2] git-apply.txt: update descriptions of --cached, --index
Date: Fri, 21 Aug 2020 09:17:18 -0700	[thread overview]
Message-ID: <xmqqv9hc9do1.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <C528Y3DXYRMW.22FBYW4FHMALJ@ziyou.local> (Raymond E. Pasco's message of "Thu, 20 Aug 2020 20:26:38 -0400")

"Raymond E. Pasco" <ray@ameretat.dev> writes:

> On Thu Aug 20, 2020 at 7:57 PM EDT, Junio C Hamano wrote:
>> I do not see why we want to stress the last part after ", even if".
>> The safety mechanism insists on the working tree file and the index
>> entry to be identical, and the location where in the file the
>> difference is, is irrelevant, whether it is outside the area the
>> incoming patch touches, or it overlaps.
>
> It's because this is the confusing part of the option - it's easy to
> grasp "apply the patch to both the working copy and the index", but
> that's not exactly what the option does, it applies only in the case of
> identical preimages (and therefore, identical postimages).

That's fair.  

Back when "git apply" was introduced, workflows to create partial
commits with "edit file; git add file; edit file; git commit" did
exist, but the safety certainly far predates the more aggressive
form of partial commits created by "add -p", "checkout -p",
etc. (which is natural, as "add -p" and friends have to use "apply"
as their implementation detail).  As "git apply --index" was created
primarily for preparing the index immediately followed by "git
commit" (as an implementation detail for "git applymbox", which was
"git am"'s precursor), it was one of the most obvious ways to avoid
the situation where _your_ work in progress in the working tree and
in the index gets mixed in the resulting commit made by applying
other's patch to insist that the index and the working tree contents
to match.  As you suggest, of course, if the user deliberately wants
to keep the index and the working tree to be different (e.g. changes
in the working tree wrt the index are outside the block of text that
is touched by any incoming patch), it is easy to bypass the safety
feature by applying to the index and to the working tree separately,
or just apply to the working tree and run another "add -p".

Having said that, I still think the half-sentence after "even if"
was of little value.  If we want to give the reason why, "even if
the patch may independently apply to the two, the two must be
identical" doesn't at all.  It complains that the description does
not explain why the two must be identical without addressing the
complaint the sentence itself raises.

And if we are not going to give why that must be so, "the index and
the working tree file must be identical" is much clearer without the
"even if" part.

      reply	other threads:[~2020-08-21 17:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-20 23:10 [PATCH v2] git-apply.txt: update descriptions of --cached, --index Raymond E. Pasco
2020-08-20 23:57 ` Junio C Hamano
2020-08-21  0:26   ` Raymond E. Pasco
2020-08-21 16:17     ` Junio C Hamano [this message]

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=xmqqv9hc9do1.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=ray@ameretat.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox