All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Karsten Blees <karsten.blees@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Misty De Meo" <misty@brew.sh>,
	"Øystein Walle" <oystwa@gmail.com>
Subject: Re: [PATCH] dir.c: fix ignore processing within not-ignored directories
Date: Sat, 1 Jun 2013 17:44:44 +0700	[thread overview]
Message-ID: <CACsJy8D4wmhGkEsn8r5OEQv_hX=OFD5W8abnBnYFcFCQZfLOoQ@mail.gmail.com> (raw)
In-Reply-To: <51A665E4.9080307@gmail.com>

On Thu, May 30, 2013 at 3:32 AM, Karsten Blees <karsten.blees@gmail.com> wrote:
> As of 95c6f271 "dir.c: unify is_excluded and is_path_excluded APIs", the
> is_excluded API no longer recurses into directories that match an ignore
> pattern, and returns the directory's ignored state for all contained paths.
>
> This is OK for normal ignore patterns, i.e. ignoring a directory affects
> the entire contents recursively.
>
> Unfortunately, this also "works" for negated ignore patterns ('!dir'), i.e.
> the entire contents is "not-ignored" recursively, regardless of ignore
> patterns that match the contents directly.
>
> In prep_exclude, skip recursing into a directory only if it is really
> ignored (i.e. the ignore pattern is not negated).
>
> Signed-off-by: Karsten Blees <blees@dcon.de>

I think I've got a hang on the "unify" patch now.

Reviewed-by: Duy Nguyen <pclouds@gmail.com>


> diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh
> +test_expect_success 'excluded directory overrides content patterns' '
> +
> +       git ls-files --others --exclude="one" --exclude="!one/a.1" >output &&
> +       if grep "^one/a.1" output

Actually I think this is a shortcoming of gitignore. You ask to
"exclude one except one/a.1" and one/a.1 should show up. '!' is
designed from day one to deal with the other way around ("include one
except one/a.1"). And it's arguable (and it was in the mail archive)
that if you already exclude "one", we should never ever descend there
to pick up "!a.1" from one/.gitignore. But we should do it with
already collected patterns, at least if we detect there are negated
patterns following the pattern that excludes a directory, e.g.
!one/a.1 or even !*.c. For the latter case, the user can always move
"!*.c" up before "one" if they don't want git to misinterpret and
descend in every excluded directory.

> +       then
> +               false
> +       fi
> +'

Nit pick, maybe this instead?

test_must_fail grep "^one/a.1" output

> +
> +test_expect_success 'negated directory doesn'\''t affect content patterns' '
> +
> +       git ls-files --others --exclude="!one" --exclude="one/a.1" >output &&
> +       if grep "^one/a.1" output
> +       then
> +               false
> +       fi
> +'

Same.
--
Duy

  reply	other threads:[~2013-06-01 10:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-28 17:54 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken? Misty De Meo
2013-05-28 21:35 ` Øystein Walle
2013-05-28 21:59   ` Junio C Hamano
2013-05-29  3:41 ` Duy Nguyen
2013-05-29  4:19   ` Duy Nguyen
2013-05-29  7:43     ` David Aguilar
2013-05-29 16:19     ` Karsten Blees
2013-05-29 18:49       ` Øystein Walle
2013-05-29 20:32       ` [PATCH] dir.c: fix ignore processing within not-ignored directories Karsten Blees
2013-06-01 10:44         ` Duy Nguyen [this message]
2013-06-02 19:25           ` Junio C Hamano
2013-06-04 16:10             ` Karsten Blees
2013-06-04 16:50             ` [PATCH] t/README: test_must_fail is for testing Git Junio C Hamano
2013-06-04 20:16               ` Philip Oakley
2013-06-04 20:49                 ` Junio C Hamano
2013-06-04 21:12                   ` Philip Oakley

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='CACsJy8D4wmhGkEsn8r5OEQv_hX=OFD5W8abnBnYFcFCQZfLOoQ@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karsten.blees@gmail.com \
    --cc=misty@brew.sh \
    --cc=oystwa@gmail.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.