All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Charles Bailey <charles@hashpling.org>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] grep: fix grepping for "intent to add" files
Date: Wed, 22 Jun 2016 18:11:35 +0200	[thread overview]
Message-ID: <CACsJy8C9Dh_Owr3UFJnCtvXserG4V-e1ws8ZY52ME1yr+fefOw@mail.gmail.com> (raw)
In-Reply-To: <xmqqinx2nonl.fsf@gitster.mtv.corp.google.com>

On Wed, Jun 22, 2016 at 12:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> @@ -396,7 +396,7 @@ static int grep_cache(struct grep_opt *opt, const struct pathspec *pathspec, int
>>                * cache version instead
>>                */
>>               if (cached || (ce->ce_flags & CE_VALID) || ce_skip_worktree(ce)) {
>> -                     if (ce_stage(ce))
>> +                     if (ce_stage(ce) || ce_intent_to_add(ce))
>>                               continue;
>>                       hit |= grep_sha1(opt, ce->sha1, ce->name, 0, ce->name);
>>               }
>
> OK, so this function handles searching in either the index or the
> working tree.
>
> The first hunk used to unconditionally discard paths marked as
> i-t-a, even when we are looking at the working tree, which is
> clearly useless, and we stop rejecting i-t-a paths too early, which
> is good.
>
> The second hunk is for "grep --cached" but also covers two other
> cases.  What are these?
>
> CE_VALID is used by "Assume unchanged".  Because the user promised
> that s/he will take responsibility of keeping the working tree
> contents in sync with what is in the index by not modifying it, even
> when we are not doing "grep --cached", we pick up the contents from
> the index and look for the string in there, instead of going to the
> working tree.  In other words, even though at the mechanical level
> we are looking into the index, logically we are searching in the
> working tree.  Is it sensible to skip i-t-a entries in that case?
>
> I think the same discussion would apply to CE_SKIP_WORKTREE (see
> "Skip-worktree bit" in Documentation/git-update-index.txt).
>
> So I wonder if a better change would be more like
>
>         for (...) {
>                 if (!S_ISREG(ce->ce_mode))
>                         continue; /* not a regular file */
>                 if (!ce_path_match(ce, pathspec, NULL)
>                         continue; /* uninteresting */
> +               if (cached && ce_intent_to_add(ce))
> +                       continue; /* path not yet in the index */
>
>                 if (cached || ...)
>                         UNCHANGED FROM THE ORIGINAL
>
> perhaps?

I did wonder a bit about these cases. But, can i-t-a really be
combined with CE_VALID or CE_SKIP_WORKTREE? CE_SKIP_... is
automatically set and should not cover i-t-a entries imo (I didn't
check the implementation). CE_VALID is about real entries, yes you
could do "git update-index --assume-unchanged <ita-path>" but it does
not feel right to me.

If cached is false and ce_ita() is true and either CE_VALID or
CE_SKIP_WORKTREE is set, we would continue to grep an _empty_ SHA-1.
But I think we should grep_file() instead, at least for CE_VALID.
-- 
Duy

  reply	other threads:[~2016-06-22 16:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-21 21:14 [PATCH v2 1/2] Fix duplicated test name Charles Bailey
2016-06-21 21:14 ` [PATCH v2 2/2] grep: fix grepping for "intent to add" files Charles Bailey
2016-06-21 22:49   ` Junio C Hamano
2016-06-22 16:11     ` Duy Nguyen [this message]
2016-06-22 18:00       ` Junio C Hamano
2016-06-22 18:32         ` Duy Nguyen
2016-06-22 19:17           ` Junio C Hamano
2016-06-22  1:13   ` Eric Sunshine
2016-06-22 16:01     ` Duy Nguyen

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=CACsJy8C9Dh_Owr3UFJnCtvXserG4V-e1ws8ZY52ME1yr+fefOw@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=charles@hashpling.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.