From: Karsten Blees <karsten.blees@gmail.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
Erik Faye-Lund <kusmabite@gmail.com>,
Robert Zeh <robert.allan.zeh@gmail.com>,
Duy Nguyen <pclouds@gmail.com>,
Antoine Pelisse <apelisse@gmail.com>,
Adam Spiers <git@adamspiers.org>
Subject: Re: [PATCH v2 01/14] dir.c: git-status --ignored: don't drop ignored directories
Date: Wed, 17 Apr 2013 02:31:01 +0200 [thread overview]
Message-ID: <516DED45.2050600@gmail.com> (raw)
In-Reply-To: <CALkWK0=0MbKnEWc+uLkbynJZXYYiRyfJ539HjtPTajHotB4q9A@mail.gmail.com>
Am 16.04.2013 19:33, schrieb Ramkumar Ramachandra:
> Firstly, great work on the series! I've just started looking into it,
> so please don't take my comments too seriously: some of them may be
> queries, and others may be minor suggestions, but I can't say I
> understand the area you're patching. I know Junio doesn't like me
> mixing queries in reviews, but I don't fully agree with his policy.
>
> Karsten Blees wrote:
>> 'git-status --ignored' drops ignored directories if they contain untracked
>> files in an untracked sub directory.
>
> Wait, ignored directories will always contain untracked
> subdirectories, unless you add -f them, right? Why are you saying
> untracked files in an _untracked_ subdirectory? We don't track
IIRC i mentioned untracked subdirectory explicitly because the problem doesn't occur if the subdirectory is tracked (i.e. contains a tracked file).
> directories anyway, and I would call a directory "tracked" if there's
> atleast one file inside it is tracked. So, my understanding of this
> is:
>
> quux/
> bar
> baz/
> foo
>
> In this example, if quux is ignored and untracked, git status
> --ignored currently shows quux/. If quux/bar is tracked (say with add
> -f), but baz/ is untracked, git status --ignored doesn't show me
> anything. What exactly is the bug you're fixing?
With your example, you get this:
1) git-status --ignored -uall: quux/baz/foo
2) git-status --ignored -unormal: <empty>
Without the untracked directory 'baz' between 'quux' and 'foo':
quux/
bar
foo
you get this:
3) git status --ignored -uall: quux/foo
4) git status --ignored -unormal: quux/
The bug is in case (2), this should be:
2) git-status --ignored -unormal: quux/
I.e. ignored directories with untracked files in untracked sub directories should be listed as ignored, because they contain ignored files. Currently these directories are not listed. I realize this sounds pretty much like the original commit message, but I don't know how to describe it any better.
> I'll try to look at
> the tests to infer this, but your commit message could probably be
> clearer.
>
> Nit: please s/git-status/git status/
Both notations (as well as just 'status') seem to be widely used. Does this justify a reroll of the entire series with changed commit messages (I believe I've used git-status / git-ls-files / git-clean consistently in all patches)?
>
>> Fix it by getting exact (recursive) excluded status in treat_directory.
>
> Okay, so you're patching treat_directory() in dir.c to do some
> recursive exclude handling. Let's see what this is.
>
>> diff --git a/dir.c b/dir.c
>> index 57394e4..ec4eebf 100644
>> --- a/dir.c
>> +++ b/dir.c
>> @@ -1060,6 +1060,15 @@ static enum directory_treatment treat_directory(struct dir_struct *dir,
>>
>> /* This is the "show_other_directories" case */
>>
>> + /* might be a sub directory in an excluded directory */
>> + if (!exclude) {
>> + struct path_exclude_check check;
>> + int dt = DT_DIR;
>> + path_exclude_check_init(&check, dir);
>> + exclude = is_path_excluded(&check, dirname, len, &dt);
>> + path_exclude_check_clear(&check);
>> + }
>> +
>
> So, I'm guessing that DT_DIR refers to a value that a field in struct
> dirent can take; that value could be one of DIR (directory), REG
> (regular file?), LNK (symbolic link?). I don't get much of this, but
> what I do get is that you're setting exclude for the rest of the code
> in this function.
>
This simply does a recursive excluded check via is_path_excluded, because is_excluded is not good enough. The rest is just boilerplate code (i.e. initialize and clear the check structure and passing a dtype == DT_DIR because dirname obviously is a directory here). We already have similar code in treat_file (and all other places that use is_path_excluded).
> Sorry that I'm not able to do a more thorough review.
>
>> diff --git a/t/t7061-wtstatus-ignore.sh b/t/t7061-wtstatus-ignore.sh
>> index 0da1214..0f1034e 100755
>> --- a/t/t7061-wtstatus-ignore.sh
>> +++ b/t/t7061-wtstatus-ignore.sh
>> @@ -143,4 +143,31 @@ test_expect_success 'status ignored tracked directory and uncommitted file with
>> test_cmp expected actual
>> '
>>
>> +cat >expected <<\EOF
>> +?? .gitignore
>> +?? actual
>> +?? expected
>> +!! tracked/
>> +EOF
>
> Please put these segments inside the test_expect_success block, so
> it's easy to think about those blocks in isolation. I know you're
> just following the existing conventions existing in this test, but
> those are not necessarily good conventions.
>
$ grep -e '^cat .*EOF$' t*.sh | wc -l
743
$ grep -e '^ cat .*EOF$' t*.sh | wc -l
22
Setting up expected results outside test_expect_* (i.e. unindented) seems to be the norm in git tests.
>> +test_expect_success 'status ignored tracked directory with uncommitted file in untracked subdir with --ignore' '
>> + rm -rf tracked/uncommitted &&
>> + mkdir tracked/ignored &&
>> + : >tracked/ignored/uncommitted &&
>> + git status --porcelain --ignored >actual &&
>> + test_cmp expected actual
>> +'
>
> This is very confusing. How is tracked a tracked directory? Oh,
> right: some previous test git add'ed tracked/committed. How do I know
> about that in this test?
>
This test expands on the previous test 'status ignored tracked directory and uncommitted file with --ignore', i.e. the test just adds the 'in untracked subdir' part (and thus moves the 'uncommitted' file into a sub directory). Expanding on previous state is the whole point of putting several tests in a single t*.sh file, right? If I wanted to set up the test fixture from scratch I would have started a new t7063-whatever.sh.
> Yeah, changes to tracked ignored directories are not shown, but the
> commit message didn't tell me this.
>
>> +cat >expected <<\EOF
>> +?? .gitignore
>> +?? actual
>> +?? expected
>> +!! tracked/ignored/uncommitted
>> +EOF
>> +
>> +test_expect_success 'status ignored tracked directory with uncommitted file in untracked subdir with --ignore -u' '
>> + git status --porcelain --ignored -u >actual &&
>> + test_cmp expected actual
>> +'
>> +
>> test_done
>
> I suppose the commit message told me about this one vaguely, but I
> think it could be much clearer overall.
>
Note that all tests in t7061 come in pairs '--ignored' (i.e. --untracked-files=normal) and '--ignored -u' (i.e. --untracked-files=all). If '-uall' lists individual ignored files, then '-unormal' should list the ignored directory.
next prev parent reply other threads:[~2013-04-17 0:31 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-18 20:28 [PATCH 0/8] Improve git-status --ignored Karsten Blees
2013-03-19 4:08 ` Junio C Hamano
2013-03-19 5:20 ` Duy Nguyen
2013-03-19 10:48 ` Karsten Blees
2013-03-19 14:48 ` Junio C Hamano
2013-03-19 15:58 ` Duy Nguyen
2013-04-15 19:04 ` [PATCH v2 00/14] " Karsten Blees
2013-04-15 19:05 ` [PATCH v2 01/14] dir.c: git-status --ignored: don't drop ignored directories Karsten Blees
2013-04-16 17:33 ` Ramkumar Ramachandra
2013-04-17 0:31 ` Karsten Blees [this message]
2013-04-15 19:06 ` [PATCH v2 02/14] dir.c: git-status --ignored: don't list files in " Karsten Blees
2013-04-16 9:57 ` [PATCH] read_revisions_from_stdin: make copies for handle_revision_arg Thomas Rast
2013-04-16 18:17 ` Junio C Hamano
2013-04-15 19:07 ` [PATCH v2 03/14] dir.c: git-status --ignored: don't list empty ignored directories Karsten Blees
2013-04-16 17:48 ` Ramkumar Ramachandra
2013-04-17 0:31 ` Karsten Blees
2013-04-15 19:08 ` [PATCH v2 04/14] dir.c: git-ls-files --directories: don't hide empty directories Karsten Blees
2013-04-15 19:08 ` [PATCH v2 05/14] dir.c: git-status --ignored: don't list empty directories as ignored Karsten Blees
2013-04-15 19:09 ` [PATCH v2 06/14] dir.c: make 'git-status --ignored' work within leading directories Karsten Blees
2013-04-15 19:10 ` [PATCH v2 07/14] dir.c: git-clean -d -X: don't delete tracked directories Karsten Blees
2013-04-15 19:11 ` [PATCH v2 08/14] dir.c: factor out parts of last_exclude_matching for later reuse Karsten Blees
2013-04-15 19:11 ` [PATCH v2 09/14] dir.c: move prep_exclude Karsten Blees
2013-04-15 19:12 ` [PATCH v2 10/14] dir.c: unify is_excluded and is_path_excluded APIs Karsten Blees
2013-04-15 21:35 ` Junio C Hamano
2013-04-15 19:12 ` [PATCH v2 11/14] dir.c: replace is_path_excluded with now equivalent is_excluded API Karsten Blees
2013-04-15 19:13 ` [PATCH v2 12/14] dir.c: git-status: avoid is_excluded checks for tracked files Karsten Blees
2013-04-15 19:14 ` [PATCH v2 13/14] dir.c: git-status --ignored: don't scan the work tree three times Karsten Blees
2013-04-15 19:15 ` [PATCH v2 14/14] dir.c: git-status --ignored: don't scan the work tree twice Karsten Blees
2013-04-15 19:23 ` [PATCH v2 00/14] Improve git-status --ignored Junio C Hamano
2013-04-15 19:33 ` Junio C Hamano
2013-04-15 20:06 ` Karsten Blees
2013-04-15 20:25 ` Junio C Hamano
2013-04-17 19:50 ` Karsten Blees
2013-04-17 22:03 ` Junio C Hamano
2013-04-17 19:50 ` [PATCH v2-pu 11/14] dir.c: replace is_path_excluded with now equivalent is_excluded API Karsten Blees
2013-04-17 19:51 ` [PATCH v2-pu 14/14] dir.c: git-status --ignored: don't scan the work tree twice Karsten Blees
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=516DED45.2050600@gmail.com \
--to=karsten.blees@gmail.com \
--cc=apelisse@gmail.com \
--cc=artagnon@gmail.com \
--cc=git@adamspiers.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kusmabite@gmail.com \
--cc=pclouds@gmail.com \
--cc=robert.allan.zeh@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 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 NNTP newsgroup(s).