git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Varun Naik <vcnaik94@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] checkout.c: unstage empty deleted ita files
Date: Sun, 28 Jul 2019 23:54:38 -0700	[thread overview]
Message-ID: <CAK_rgsH6hL3g+PVfcMuq1dQLeNJcii=D_dQ8anmWLvYrShmkNg@mail.gmail.com> (raw)
In-Reply-To: <20190726085756.GA20017@sigill.intra.peff.net>

On Fri, Jul 26, 2019 at 1:57 AM Jeff King <peff@peff.net> wrote:
>
> On Thu, Jul 25, 2019 at 09:56:45PM -0700, Varun Naik wrote:
>
> > It is possible to delete a committed file from the index and then add it
> > as intent-to-add. After `git checkout HEAD` or `git restore --staged`,
> > the file should be identical in the index and HEAD. This patch provides
> > the desired behavior even when the file is empty in the index.
>
> OK, so the issue is that ITA entries have an empty-file sha1, so they
> confuse the logic to decide if we can use the old entry. Your fix makes
> sense.
>
> > ---
> > CC Jeff because you wrote the code that I am changing now.
> >
> > checkout.c:update_some() discards the newly created cache entry when its
> > mode and oid match those of the old entry. Since an ita file has the
> > same oid as an empty file, an empty deleted ita file passes both of
> > these checks, and the new entry is discarded. In this case, the file
> > should be added to the cache instead.
> >
> > This change should not affect newly added ita files. For those, inside
> > tree.c:read_tree_1(), tree_entry_interesting() returns
> > entry_not_interesting, so fn (which points to update_some()) is never
> > called.
>
> These two paragraphs would be a nice addition to the actual commit
> message.
>

I will add them to the commit message, with some minor changes.

> > diff --git a/builtin/checkout.c b/builtin/checkout.c
> > index 91f8509f85..27daa09c3c 100644
> > --- a/builtin/checkout.c
> > +++ b/builtin/checkout.c
> > @@ -126,6 +126,7 @@ static int update_some(const struct object_id *oid, struct strbuf *base,
> >       if (pos >= 0) {
> >               struct cache_entry *old = active_cache[pos];
> >               if (ce->ce_mode == old->ce_mode &&
> > +                 !ce_intent_to_add(old) &&
> >                   oideq(&ce->oid, &old->oid)) {
> >                       old->ce_flags |= CE_UPDATE;
> >                       discard_cache_entry(ce);
>
> My first thought here was that we could skip ITA entries here only when
> the HEAD hash is also the empty blob, which would let us retain index
> results in more cases. But it doesn't help. If the HEAD entry isn't the
> empty blob, then we'll have !oideq() and we'll skip anyway, because an
> ITA entry must be the empty blob (if we `git add` some other content,
> then it ceases to be ITA).
>
> So it makes sense to just always skip this "retain the old index entry"
> block for any ITA entry.
>
> > +test_expect_success 'checkout HEAD adds deleted intent-to-add file back to index' '
> > +     echo "nonempty" >nonempty &&
> > +     >empty &&
> > +     git add nonempty empty &&
> > +     git commit -m "create files to be deleted" &&
> > +     git rm --cached nonempty empty &&
> > +     git add -N nonempty empty &&
> > +     git checkout HEAD nonempty empty &&
> > +     git diff --staged --exit-code
> > +'
>
> This clearly demonstrates the problem. Nice.
>
> > +test_expect_success 'restore --staged adds deleted intent-to-add file back to index' '
> > +     echo "nonempty" >nonempty &&
> > +     >empty &&
> > +     git add nonempty empty &&
> > +     git commit -m "create files to be deleted" &&
> > +     git rm --cached nonempty empty &&
> > +     git add -N nonempty empty &&
> > +     git restore --staged nonempty empty &&
> > +     git diff --staged --exit-code
> > +'
>
> Hmm. This git-restore test means we don't apply to maint. But wouldn't
> we want the fix for "checkout" there?
>
> I.e., I'd expect a patch to fix and test git-checkout, and then an
> additional patch to be added on the merge of that plus master to test
> git-restore.
>

To make sure I understand, do you mean that I should omit the test
case for "restore" right now, wait for the patch to reach master, and
then create another patch for the "restore" test case?

> Other than that, the patch looks good to me.
>
> -Peff

Varun

  reply	other threads:[~2019-07-29  6:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-26  4:56 [PATCH] checkout.c: unstage empty deleted ita files Varun Naik
2019-07-26  5:01 ` Varun Naik
2019-07-26  8:57 ` Jeff King
2019-07-29  6:54   ` Varun Naik [this message]
2019-07-29  9:11     ` Jeff King
2019-08-01 16:07 ` [PATCH v2] " Varun Naik
2019-08-01 17:34   ` Junio C Hamano
2019-08-01 21:51   ` Jeff King
2019-08-01 16:09 ` [PATCH] restore: add test for " Varun Naik
2019-08-02 16:16   ` Junio C Hamano
2019-08-02 16:28 ` [PATCH v3] checkout.c: unstage empty " Varun Naik

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='CAK_rgsH6hL3g+PVfcMuq1dQLeNJcii=D_dQ8anmWLvYrShmkNg@mail.gmail.com' \
    --to=vcnaik94@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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).