public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail•com>
Cc: git@vger•kernel.org, Eric Sunshine <sunshine@sunshineco•com>
Subject: Re: [PATCH v2 2/2] dir.c: don't exclude whole dir prematurely if neg pattern may match
Date: Mon, 14 Sep 2015 10:15:11 -0700	[thread overview]
Message-ID: <xmqqd1xkylb4.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1442107141-24265-3-git-send-email-pclouds@gmail.com> ("Nguyễn	Thái Ngọc Duy"'s message of "Sun, 13 Sep 2015 08:19:01 +0700")

Nguyễn Thái Ngọc Duy  <pclouds@gmail•com> writes:

> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
> index 473623d..889a72a 100644
> --- a/Documentation/gitignore.txt
> +++ b/Documentation/gitignore.txt
> @@ -82,12 +82,9 @@ PATTERN FORMAT
>  
>   - An optional prefix "`!`" which negates the pattern; any
>     matching file excluded by a previous pattern will become
> +   included again. It is possible to re-include a file if a parent
> +   directory of that file is excluded, with restrictions. See section
> +   NOTES for detail.

Sounds like a very useful thing.

>   - If the pattern ends with a slash, it is removed for the
>     purpose of the following description, but it would only find
> @@ -141,6 +138,18 @@ not tracked by Git remain untracked.
>  To stop tracking a file that is currently tracked, use
>  'git rm --cached'.
>  
> +To re-include a file when its parent directory is excluded, the
> +following conditions must be met:
> +
> + - The directory part in the re-include rules must be literal (i.e. no
> +   wildcards)
> +
> + - The rules to exclude the parent directory must not end with a
> +   trailing slash.
> +
> + - The rules to exclude the parent directory must have at least one
> +   slash.
> +

In this bulletted list, don't the readers also need to be told that
having "/abc" in .gitignore (but not "!/abc/anything" in .gitignore)
and "!foo" in abc/.gitignore would not cause us to descend into
"/abc" just to examine "abc/.gitignore" with pessimistic assumption
that there might be some exclusion in there?

> diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh
> index 3fc484e..9de49a6 100755
> --- a/t/t3001-ls-files-others-exclude.sh
> +++ b/t/t3001-ls-files-others-exclude.sh
> @@ -305,4 +305,24 @@ test_expect_success 'ls-files with "**" patterns and no slashes' '
>  	test_cmp expect actual
>  '
>  
> +test_expect_success 'negative patterns' '
> +	git init reinclude &&
> +	(
> +		cd reinclude &&
> +		cat >.gitignore <<-\EOF &&
> +		/foo
> +		!foo/bar/bar
> +		EOF
> +		mkdir -p foo/bar &&
> +		touch abc foo/def foo/bar/ghi foo/bar/bar &&
> +		git ls-files -o --exclude-standard >../actual &&
> +		cat >../expected <<-\EOF &&
> +		.gitignore
> +		abc
> +		foo/bar/bar
> +		EOF
> +		test_cmp ../expected ../actual
> +	)
> +'

And another test here may want to explicitly ensure that we are not
overly pessimising the ignore processing, so that later changes will
not break it, I think.  Or do we already have such a case covered by
an existing test?

Thanks.

  reply	other threads:[~2015-09-14 17:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-23 12:50 [PATCH 0/2] gitignore, re-inclusion fix Nguyễn Thái Ngọc Duy
2015-08-23 12:50 ` [PATCH 1/2] dir.c: make last_exclude_matching_from_list() run til the end Nguyễn Thái Ngọc Duy
2015-08-25 20:28   ` Junio C Hamano
2015-08-31 10:13     ` Duy Nguyen
2015-08-23 12:50 ` [PATCH 2/2] dir.c: don't exclude whole dir prematurely if neg pattern may match Nguyễn Thái Ngọc Duy
2015-09-13  1:18 ` [PATCH v2 0/2] gitignore, re-inclusion fix Nguyễn Thái Ngọc Duy
2015-09-13  1:19   ` [PATCH v2 1/2] dir.c: make last_exclude_matching_from_list() run til the end Nguyễn Thái Ngọc Duy
2015-09-13  1:19   ` [PATCH v2 2/2] dir.c: don't exclude whole dir prematurely if neg pattern may match Nguyễn Thái Ngọc Duy
2015-09-14 17:15     ` Junio C Hamano [this message]
2015-09-17 13:21       ` 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=xmqqd1xkylb4.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=pclouds@gmail$(echo .)com \
    --cc=sunshine@sunshineco$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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