{"thread":{"id":"33962","subject":"1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?","startedAt":"2013-05-28T17:54:15Z","lastAt":"2013-06-04T21:12:06Z","messageCount":16,"participants":["Misty De Meo","Øystein Walle","Junio C Hamano","Duy Nguyen","David Aguilar","Karsten Blees","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"218688","messageId":"CAGLuM14_MQffwQWrB2YCQXzhkGaxdaYBuY74y7=pfb-hB6LskA@mail.gmail.com","threadId":"33962","inReplyTo":null,"subject":"1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?","fromName":"Misty De Meo","fromEmail":"misty@brew.sh","sentAt":"2013-05-28T17:54:15Z","receivedAt":"2013-05-28T17:54:15Z","isPatch":false,"sender":{"key":"misty@brew.sh","avatar":null},"body":"Hi,\n\nGitignore parsing no longer seems to work properly in git 1.8.3.\n\nOne of my repositories has the following gitignore:\n\n/*\n!/.gitignore\n!/Library/\n!/CONTRIBUTING.md\n!/README.md\n!/SUPPORTERS.md\n!/bin\n/bin/*\n!/bin/brew\n!/share/man/man1/brew.1\n.DS_Store\n/Library/LinkedKegs\n/Library/PinnedKegs\n/Library/Taps\n/Library/Formula/.gitignore\n\nIn 1.8.2.3 and earlier, this works as expected. However, in 1.8.3 I'm\nseeing every file in /bin/ being marked as an untracked file.\n\nI asked about this in #git, and was told that the culprit was the\nregex support; apparently recompiling without regex support fixes the\nspecific gitignore issue. However, this doesn't seem to have been\nreported anywhere on the mailing list that I can see. I was also told\nthat the issue is OS X-specific, and doesn't happen on other\nplatforms.\n\nThanks,\nMisty De Meo\n"},{"id":"218701","messageId":"loom.20130528T232459-307@post.gmane.org","threadId":"33962","inReplyTo":"CAGLuM14_MQffwQWrB2YCQXzhkGaxdaYBuY74y7=pfb-hB6LskA@mail.gmail.com","subject":"Re: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?","fromName":"Øystein Walle","fromEmail":"oystwa@gmail.com","sentAt":"2013-05-28T21:35:01Z","receivedAt":"2013-05-28T21:35:01Z","isPatch":false,"sender":{"key":"oystwa@gmail.com","avatar":"https://avatars.githubusercontent.com/u/794585?v=4"},"body":"Misty De Meo brew.sh> writes:\n\n> \n> Hi,\n> \n> Gitignore parsing no longer seems to work properly in git 1.8.3.\n> \n> One of my repositories has the following gitignore:\n> \n> /*\n> !/.gitignore\n> !/Library/\n> !/CONTRIBUTING.md\n> !/README.md\n> !/SUPPORTERS.md\n> !/bin\n> /bin/*\n> !/bin/brew\n> !/share/man/man1/brew.1\n> .DS_Store\n> /Library/LinkedKegs\n> /Library/PinnedKegs\n> /Library/Taps\n> /Library/Formula/.gitignore\n> \n> In 1.8.2.3 and earlier, this works as expected. However, in 1.8.3 I'm\n> seeing every file in /bin/ being marked as an untracked file.\n> \n> I asked about this in #git, and was told that the culprit was the\n> regex support; apparently recompiling without regex support fixes the\n> specific gitignore issue. However, this doesn't seem to have been\n> reported anywhere on the mailing list that I can see. I was also told\n> that the issue is OS X-specific, and doesn't happen on other\n> platforms.\n> \n> Thanks,\n> Misty De Meo\n> \n\nI see a similar problem using e.g. the following .gitignore to exclude\neverything except C source files and header files:\n\n *\n !*/\n !*.c\n !*.h\n\nIn Git 1.8.3 'git status' will show other files as untracked while in\nGit 1.8.2.3 I don't have that problem. I bisected to find that the\noffending commit is v1.8.2.1-402-g95c6f27. \n\nI am not on OSX, however, but on Linux (Ubuntu 12.04 and RHEL 5.8) so\nthis may be a separate issue. I've also gotten the impression that this\nis intentional. In any case I cannot create a .gitignore that achieves\nthe same for both older and newer versions of Git.\n\nBest regards,\nØystein Walle\n"},{"id":"218703","messageId":"7vhahmydcy.fsf@alter.siamese.dyndns.org","threadId":"33962","inReplyTo":"loom.20130528T232459-307@post.gmane.org","subject":"Re: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-28T21:59:57Z","receivedAt":"2013-05-28T21:59:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Øystein Walle writes:\n\n> Misty De Meo brew.sh> writes:\n>\n>> \n>> Hi,\n>> \n>> Gitignore parsing no longer seems to work properly in git 1.8.3.\n>> \n>> One of my repositories has the following gitignore:\n>> \n>> /*\n>> !/.gitignore\n>> !/Library/\n>> !/CONTRIBUTING.md\n>> !/README.md\n>> !/SUPPORTERS.md\n>> !/bin\n>> /bin/*\n>> !/bin/brew\n>> !/share/man/man1/brew.1\n>> .DS_Store\n>> /Library/LinkedKegs\n>> /Library/PinnedKegs\n>> /Library/Taps\n>> /Library/Formula/.gitignore\n>> \n>> In 1.8.2.3 and earlier, this works as expected. However, in 1.8.3 I'm\n>> seeing every file in /bin/ being marked as an untracked file.\n>> \n>> I asked about this in #git, and was told that the culprit was the\n>> regex support; apparently recompiling without regex support fixes the\n>> specific gitignore issue. However, this doesn't seem to have been\n>> reported anywhere on the mailing list that I can see. I was also told\n>> that the issue is OS X-specific, and doesn't happen on other\n>> platforms.\n>> \n>> Thanks,\n>> Misty De Meo\n>> \n>\n> I see a similar problem using e.g. the following .gitignore to exclude\n> everything except C source files and header files:\n>\n> *\n> !*/\n> !*.c\n> !*.h\n>\n> In Git 1.8.3 'git status' will show other files as untracked while in\n> Git 1.8.2.3 I don't have that problem. I bisected to find that the\n> offending commit is v1.8.2.1-402-g95c6f27. \n>\n> I am not on OSX, however, but on Linux (Ubuntu 12.04 and RHEL 5.8) so\n> this may be a separate issue. I've also gotten the impression that this\n> is intentional. In any case I cannot create a .gitignore that achieves\n> the same for both older and newer versions of Git.\n\nThanks; 95c6f27 is from Karsten and I think Duy is the most clueful\none in this area in the discussion that had this change; I am\nforwarding this message to them.\n\nCf. http://thread.gmane.org/gmane.comp.version-control.git/218440/focus=221289\n"},{"id":"218725","messageId":"CACsJy8BqCUKhc8vhjhNz0OedBngk7zcSOk70ekRm3EiruHfNxA@mail.gmail.com","threadId":"33962","inReplyTo":"CAGLuM14_MQffwQWrB2YCQXzhkGaxdaYBuY74y7=pfb-hB6LskA@mail.gmail.com","subject":"Re: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-29T03:41:30Z","receivedAt":"2013-05-29T03:41:30Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, May 29, 2013 at 12:54 AM, Misty De Meo wrote:\n> Hi,\n>\n> Gitignore parsing no longer seems to work properly in git 1.8.3.\n>\n> One of my repositories has the following gitignore:\n>\n> /*\n> !/.gitignore\n> !/Library/\n> !/CONTRIBUTING.md\n> !/README.md\n> !/SUPPORTERS.md\n> !/bin\n> /bin/*\n> !/bin/brew\n> !/share/man/man1/brew.1\n> .DS_Store\n> /Library/LinkedKegs\n> /Library/PinnedKegs\n> /Library/Taps\n> /Library/Formula/.gitignore\n>\n> In 1.8.2.3 and earlier, this works as expected. However, in 1.8.3 I'm\n> seeing every file in /bin/ being marked as an untracked file.\n\nThe changes in this area since 1.8.2.3 seem to be Karsten's (I'm not\nblaming, just wanted to narrow down the problem). The patterns of\ninterest seem to be\n\n!/bin\n/bin/*\n!/bin/brew\n\nWithout \"!/bin\" v1.8.3 seems to behave the same as v1.8.2.3. Can you verify it?\n\n> I asked about this in #git, and was told that the culprit was the\n> regex support; apparently recompiling without regex support fixes the\n> specific gitignore issue. However, this doesn't seem to have been\n> reported anywhere on the mailing list that I can see. I was also told\n> that the issue is OS X-specific, and doesn't happen on other\n> platforms.\n\nPuzzled. regex has nothing to do with gitignore (glob does). How do\nyou recompile without regex support? Setting NO_REGEX? I'm on Linux\nbtw, no chance of touching OS X.\n--\nDuy\n"},{"id":"218744","messageId":"CACsJy8DD=LxAKh_fUELJ5Mj0xS_gZE88N_rJFkKGer=YAOqsMg@mail.gmail.com","threadId":"33962","inReplyTo":"CACsJy8BqCUKhc8vhjhNz0OedBngk7zcSOk70ekRm3EiruHfNxA@mail.gmail.com","subject":"Re: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-29T04:19:43Z","receivedAt":"2013-05-29T04:19:43Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, May 29, 2013 at 10:41 AM, Duy Nguyen wrote:\n> The changes in this area since 1.8.2.3 seem to be Karsten's (I'm not\n> blaming, just wanted to narrow down the problem). The patterns of\n> interest seem to be\n>\n> !/bin\n> /bin/*\n> !/bin/brew\n>\n> Without \"!/bin\" v1.8.3 seems to behave the same as v1.8.2.3.\n\nKarsten, the block \"/* Abort if the directory is excluded */\" in\nprep_exclude() seems to cause this. I think it goes through the\nexclude patterns, hits \"!/bin\", believes the patterns do not make\nsense in this context and throws all away. I think Øystein's case\nfalls into the same path. Commenting out the block seems to gain the\nold behavior back (and probably breaks other stuff). Contrary to what\nJunio said, I'm clueless about this. I wanted to read your series\nthrough and eventually gave up. I think I now have the motivation to\nlook at it again this weekend.\n--\nDuy\n"},{"id":"218779","messageId":"CAJDDKr5VXvbQ8Ww7P=R2Abgr93jQ0r2Lq1GNTdZKfByjSqZWrQ@mail.gmail.com","threadId":"33962","inReplyTo":"CACsJy8DD=LxAKh_fUELJ5Mj0xS_gZE88N_rJFkKGer=YAOqsMg@mail.gmail.com","subject":"Re: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2013-05-29T07:43:14Z","receivedAt":"2013-05-29T07:43:14Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Tue, May 28, 2013 at 9:19 PM, Duy Nguyen wrote:\n> On Wed, May 29, 2013 at 10:41 AM, Duy Nguyen wrote:\n>> The changes in this area since 1.8.2.3 seem to be Karsten's (I'm not\n>> blaming, just wanted to narrow down the problem). The patterns of\n>> interest seem to be\n>>\n>> !/bin\n>> /bin/*\n>> !/bin/brew\n>>\n>> Without \"!/bin\" v1.8.3 seems to behave the same as v1.8.2.3.\n>\n> Karsten, the block \"/* Abort if the directory is excluded */\" in\n> prep_exclude() seems to cause this. I think it goes through the\n> exclude patterns, hits \"!/bin\", believes the patterns do not make\n> sense in this context and throws all away. I think Øystein's case\n> falls into the same path. Commenting out the block seems to gain the\n> old behavior back (and probably breaks other stuff). Contrary to what\n> Junio said, I'm clueless about this. I wanted to read your series\n> through and eventually gave up. I think I now have the motivation to\n> look at it again this weekend.\n\nThe very first patch in the da/darwin series in \"next\" is one possible fix.\n\nSee 29de20504e9790785fe1698300755323f74972aa\n\n Makefile: fix default regex settings on Darwin\n\n t0070-fundamental.sh fails on Mac OS X 10.8:\n\n $ uname -a\n Darwin lustrous 12.2.0 Darwin Kernel Version 12.2.0:\n Sat Aug 25 00:48:52 PDT 2012;\n root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64\n\n $ ./t0070-fundamental.sh -v\n fatal: regex bug confirmed: re-build git with NO_REGEX=1\n\n Fix it by using Git's regex library.\n\nDoes that patch also fix this issue?\n\nKarsten, you mentioned that compiling without regex support fixes it for you.\nDoes the above commit in git.git's \"next\" branch fix it too?\n\nIf so, I think it would be worth merging this early part into a \"maint\" release.\n--\nDavid\n"},{"id":"218849","messageId":"51A62A96.6040009@gmail.com","threadId":"33962","inReplyTo":"CACsJy8DD=LxAKh_fUELJ5Mj0xS_gZE88N_rJFkKGer=YAOqsMg@mail.gmail.com","subject":"Re: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-05-29T16:19:34Z","receivedAt":"2013-05-29T16:19:34Z","isPatch":false,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"Am 29.05.2013 06:19, schrieb Duy Nguyen:\n> On Wed, May 29, 2013 at 10:41 AM, Duy Nguyen wrote:\n>> The changes in this area since 1.8.2.3 seem to be Karsten's (I'm not\n>> blaming, just wanted to narrow down the problem). The patterns of\n>> interest seem to be\n>>\n>> !/bin\n>> /bin/*\n>> !/bin/brew\n>>\n>> Without \"!/bin\" v1.8.3 seems to behave the same as v1.8.2.3.\n> \n> Karsten, the block \"/* Abort if the directory is excluded */\" in\n> prep_exclude() seems to cause this. I think it goes through the\n> exclude patterns, hits \"!/bin\", believes the patterns do not make\n> sense in this context and throws all away.\n\nYes, I forgot to check the \"!\" flag to determine if the directory is really excluded. I'll prepare a patch + test case for this.\n\n@Øystein: in the meantime, could you check if this fixes the problem for you?\n\n--- 8< ---\ndiff --git a/dir.c b/dir.c\nindex a5926fb..13858fe 100644\n--- a/dir.c\n+++ b/dir.c\n@@ -821,6 +821,9 @@ static void prep_exclude(struct dir_struct *dir, const char *base, int baselen)\n \t\t\t\tdir->basebuf, stk->baselen - 1,\n \t\t\t\tdir->basebuf + current, &dt);\n \t\t\tdir->basebuf[stk->baselen - 1] = '/';\n+\t\t\tif (dir->exclude &&\n+\t\t\t dir->exclude->flags & EXC_FLAG_NEGATIVE)\n+\t\t\t\tdir->exclude = NULL;\n \t\t\tif (dir->exclude) {\n \t\t\t\tdir->basebuf[stk->baselen] = 0;\n \t\t\t\tdir->exclude_stack = stk;\n-- \n"},{"id":"218877","messageId":"loom.20130529T204310-306@post.gmane.org","threadId":"33962","inReplyTo":"51A62A96.6040009@gmail.com","subject":"Re: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?","fromName":"Øystein Walle","fromEmail":"oystwa@gmail.com","sentAt":"2013-05-29T18:49:58Z","receivedAt":"2013-05-29T18:49:58Z","isPatch":false,"sender":{"key":"oystwa@gmail.com","avatar":"https://avatars.githubusercontent.com/u/794585?v=4"},"body":"Karsten Blees gmail.com> writes:\n\n> Øystein: in the meantime, could you check if this fixes the problem \nfor you?\n> \n> --- 8< ---\n> diff --git a/dir.c b/dir.c\n> index a5926fb..13858fe 100644\n> --- a/dir.c\n> +++ b/dir.c\n> -821,6 +821,9 static void prep_exclude(struct \ndir_struct *dir, const char *base, int baselen)\n> \t\t\t\tdir->basebuf, stk->baselen - 1,\n> \t\t\t\tdir->basebuf + current, &dt);\n> \t\t\tdir->basebuf[stk->baselen - 1] = '/';\n> +\t\t\tif (dir->exclude &&\n> +\t\t\t dir->exclude->flags & EXC_FLAG_NEGATIVE)\n> +\t\t\t\tdir->exclude = NULL;\n> \t\t\tif (dir->exclude) {\n> \t\t\t\tdir->basebuf[stk->baselen] = 0;\n> \t\t\t\tdir->exclude_stack = stk;\n\nHi, Karsten\n\nI applied your fix on v1.8.3 on both systems I mentioned earlier and\nfrom my tests the issue I reported is fixed.\n\nThank you very much! :)\n\nRegards\nØsse\n"},{"id":"218899","messageId":"51A665E4.9080307@gmail.com","threadId":"33962","inReplyTo":"51A62A96.6040009@gmail.com","subject":"[PATCH] dir.c: fix ignore processing within not-ignored directories","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-05-29T20:32:36Z","receivedAt":"2013-05-29T20:32:36Z","isPatch":true,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"As of 95c6f271 \"dir.c: unify is_excluded and is_path_excluded APIs\", the\nis_excluded API no longer recurses into directories that match an ignore\npattern, and returns the directory's ignored state for all contained paths.\n\nThis is OK for normal ignore patterns, i.e. ignoring a directory affects\nthe entire contents recursively.\n\nUnfortunately, this also \"works\" for negated ignore patterns ('!dir'), i.e.\nthe entire contents is \"not-ignored\" recursively, regardless of ignore\npatterns that match the contents directly.\n\nIn prep_exclude, skip recursing into a directory only if it is really\nignored (i.e. the ignore pattern is not negated).\n\nSigned-off-by: Karsten Blees \n---\n\nAlso available here:\nhttps://github.com/kblees/git/tree/kb/ignore-within-not-ignored-dir\ngit pull git://github.com/kblees/git.git kb/ignore-within-not-ignored-dir\n\n dir.c | 3 +++\n t/t3001-ls-files-others-exclude.sh | 18 ++++++++++++++++++\n 2 files changed, 21 insertions(+)\n\ndiff --git a/dir.c b/dir.c\nindex a5926fb..13858fe 100644\n--- a/dir.c\n+++ b/dir.c\n@@ -821,6 +821,9 @@ static void prep_exclude(struct dir_struct *dir, const char *base, int baselen)\n \t\t\t\tdir->basebuf, stk->baselen - 1,\n \t\t\t\tdir->basebuf + current, &dt);\n \t\t\tdir->basebuf[stk->baselen - 1] = '/';\n+\t\t\tif (dir->exclude &&\n+\t\t\t dir->exclude->flags & EXC_FLAG_NEGATIVE)\n+\t\t\t\tdir->exclude = NULL;\n \t\t\tif (dir->exclude) {\n \t\t\t\tdir->basebuf[stk->baselen] = 0;\n \t\t\t\tdir->exclude_stack = stk;\ndiff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh\nindex 4e3735f..f0421c0 100755\n--- a/t/t3001-ls-files-others-exclude.sh\n+++ b/t/t3001-ls-files-others-exclude.sh\n@@ -175,6 +175,24 @@ test_expect_success 'negated exclude matches can override previous ones' '\n \tgrep \"^a.1\" output\n '\n \n+test_expect_success 'excluded directory overrides content patterns' '\n+\n+\tgit ls-files --others --exclude=\"one\" --exclude=\"!one/a.1\" >output &&\n+\tif grep \"^one/a.1\" output\n+\tthen\n+\t\tfalse\n+\tfi\n+'\n+\n+test_expect_success 'negated directory doesn'\\''t affect content patterns' '\n+\n+\tgit ls-files --others --exclude=\"!one\" --exclude=\"one/a.1\" >output &&\n+\tif grep \"^one/a.1\" output\n+\tthen\n+\t\tfalse\n+\tfi\n+'\n+\n test_expect_success 'subdirectory ignore (setup)' '\n \tmkdir -p top/l1/l2 &&\n \t(\n-- \n1.8.3.8097.gdc25f02.dirty\n"},{"id":"219129","messageId":"CACsJy8D4wmhGkEsn8r5OEQv_hX=OFD5W8abnBnYFcFCQZfLOoQ@mail.gmail.com","threadId":"33962","inReplyTo":"51A665E4.9080307@gmail.com","subject":"Re: [PATCH] dir.c: fix ignore processing within not-ignored directories","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-01T10:44:44Z","receivedAt":"2013-06-01T10:44:44Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 30, 2013 at 3:32 AM, Karsten Blees wrote:\n> As of 95c6f271 \"dir.c: unify is_excluded and is_path_excluded APIs\", the\n> is_excluded API no longer recurses into directories that match an ignore\n> pattern, and returns the directory's ignored state for all contained paths.\n>\n> This is OK for normal ignore patterns, i.e. ignoring a directory affects\n> the entire contents recursively.\n>\n> Unfortunately, this also \"works\" for negated ignore patterns ('!dir'), i.e.\n> the entire contents is \"not-ignored\" recursively, regardless of ignore\n> patterns that match the contents directly.\n>\n> In prep_exclude, skip recursing into a directory only if it is really\n> ignored (i.e. the ignore pattern is not negated).\n>\n> Signed-off-by: Karsten Blees \n\nI think I've got a hang on the \"unify\" patch now.\n\nReviewed-by: Duy Nguyen \n\n\n> diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh\n> +test_expect_success 'excluded directory overrides content patterns' '\n> +\n> + git ls-files --others --exclude=\"one\" --exclude=\"!one/a.1\" >output &&\n> + if grep \"^one/a.1\" output\n\nActually I think this is a shortcoming of gitignore. You ask to\n\"exclude one except one/a.1\" and one/a.1 should show up. '!' is\ndesigned from day one to deal with the other way around (\"include one\nexcept one/a.1\"). And it's arguable (and it was in the mail archive)\nthat if you already exclude \"one\", we should never ever descend there\nto pick up \"!a.1\" from one/.gitignore. But we should do it with\nalready collected patterns, at least if we detect there are negated\npatterns following the pattern that excludes a directory, e.g.\n!one/a.1 or even !*.c. For the latter case, the user can always move\n\"!*.c\" up before \"one\" if they don't want git to misinterpret and\ndescend in every excluded directory.\n\n> + then\n> + false\n> + fi\n> +'\n\nNit pick, maybe this instead?\n\ntest_must_fail grep \"^one/a.1\" output\n\n> +\n> +test_expect_success 'negated directory doesn'\\''t affect content patterns' '\n> +\n> + git ls-files --others --exclude=\"!one\" --exclude=\"one/a.1\" >output &&\n> + if grep \"^one/a.1\" output\n> + then\n> + false\n> + fi\n> +'\n\nSame.\n--\nDuy\n"},{"id":"219184","messageId":"7vk3mcnwlj.fsf@alter.siamese.dyndns.org","threadId":"33962","inReplyTo":"CACsJy8D4wmhGkEsn8r5OEQv_hX=OFD5W8abnBnYFcFCQZfLOoQ@mail.gmail.com","subject":"Re: [PATCH] dir.c: fix ignore processing within not-ignored directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-02T19:25:44Z","receivedAt":"2013-06-02T19:25:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n>> + then\n>> + false\n>> + fi\n>> +'\n>\n> Nit pick, maybe this instead?\n>\n> test_must_fail grep \"^one/a.1\" output\n\nNeither.\n\n\t! grep \"^one/a.1\" output\n\nThe second bullet point in the \"Don't\" section of t/README may want\nto be updated to clarify that test_must_fail is to test Git, and we\ndo not mean to catch segfaults by platform tools like grep.\n"},{"id":"219376","messageId":"51AE1170.8090402@gmail.com","threadId":"33962","inReplyTo":"7vk3mcnwlj.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] dir.c: fix ignore processing within not-ignored directories","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-06-04T16:10:24Z","receivedAt":"2013-06-04T16:10:24Z","isPatch":true,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"Am 02.06.2013 21:25, schrieb Junio C Hamano:\n> Duy Nguyen writes:\n> \n>>> + then\n>>> + false\n>>> + fi\n>>> +'\n>>\n>> Nit pick, maybe this instead?\n>>\n>> test_must_fail grep \"^one/a.1\" output\n> \n> Neither.\n> \n> \t! grep \"^one/a.1\" output\n> \n\nNice. I actually tried \"!\" but without the space - which didn't work so I took the other t3001 tests as example...\n"},{"id":"219380","messageId":"7vppw195x7.fsf_-_@alter.siamese.dyndns.org","threadId":"33962","inReplyTo":"7vk3mcnwlj.fsf@alter.siamese.dyndns.org","subject":"[PATCH] t/README: test_must_fail is for testing Git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-04T16:50:12Z","receivedAt":"2013-06-04T16:50:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When a test wants to make sure there is no in an output\nfile, we should just say \"! grep string output\"; \"test_must_fail\"\nis there only to test Git command and catch unusual deaths we know\nabout (e.g. segv) as an error, not as an expected failure.\n\nSigned-off-by: Junio C Hamano \n---\n t/README | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/t/README b/t/README\nindex e669bb3..35b3c5c 100644\n--- a/t/README\n+++ b/t/README\n@@ -324,6 +324,9 @@ Don't:\n use 'test_must_fail git cmd'. This will signal a failure if git\n dies in an unexpected way (e.g. segfault).\n \n+ On the other hand, don't use test_must_fail for running regular\n+ platform commands; just use '! cmd'.\n+\n - use perl without spelling it as \"$PERL_PATH\". This is to help our\n friends on Windows where the platform Perl often adds CR before\n the end of line, and they bundle Git with a version of Perl that\n"},{"id":"219401","messageId":"AAD729AEE8D044B89388799A7CC7552A@PhilipOakley","threadId":"33962","inReplyTo":"7vppw195x7.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] t/README: test_must_fail is for testing Git","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-06-04T20:16:38Z","receivedAt":"2013-06-04T20:16:38Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Tuesday, June 04, 2013 5:50 PM\n> When a test wants to make sure there is no in an output\n> file, we should just say \"! grep string output\";\n\nSmall nit: It took me two readings of the commit message to correctly \nparse this break point. The flowing together of the two parts with the \nsemicolon fooled me. Separate them?\n\n> \"test_must_fail\"\n> is there only to test Git command and catch unusual deaths we know\n> about (e.g. segv) as an error, not as an expected failure.\n>\n> Signed-off-by: Junio C Hamano \n> ---\n> t/README | 3 +++\n> 1 file changed, 3 insertions(+)\n>\n> diff --git a/t/README b/t/README\n> index e669bb3..35b3c5c 100644\n> --- a/t/README\n> +++ b/t/README\n> @@ -324,6 +324,9 @@ Don't:\n> use 'test_must_fail git cmd'. This will signal a failure if git\n> dies in an unexpected way (e.g. segfault).\n>\n> + On the other hand, don't use test_must_fail for running regular\n> + platform commands; just use '! cmd'.\n> +\n> - use perl without spelling it as \"$PERL_PATH\". This is to help our\n> friends on Windows where the platform Perl often adds CR before\n> the end of line, and they bundle Git with a version of Perl that\n> --\n\nPhilip \n"},{"id":"219403","messageId":"7v1u8h7gac.fsf@alter.siamese.dyndns.org","threadId":"33962","inReplyTo":"AAD729AEE8D044B89388799A7CC7552A@PhilipOakley","subject":"Re: [PATCH] t/README: test_must_fail is for testing Git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-04T20:49:15Z","receivedAt":"2013-06-04T20:49:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> From: \"Junio C Hamano\" \n> Sent: Tuesday, June 04, 2013 5:50 PM\n>> When a test wants to make sure there is no in an output\n>> file, we should just say \"! grep string output\";\n>\n> Small nit: It took me two readings of the commit message to correctly\n> parse this break point. The flowing together of the two parts with the\n> semicolon fooled me. Separate them?\n>\n>> \"test_must_fail\"\n>> is there only to test Git command and catch unusual deaths we know\n>> about (e.g. segv) as an error, not as an expected failure.\n\nThanks. Does this read better?\n\n t/README: test_must_fail is for testing Git\n \n When a test wants to make sure there is no in an output\n file, we should just say \"! grep string output\".\n \n \"test_must_fail\" is there only to test Git command and catch unusual\n deaths we know about (e.g. segv) as an error, not as an expected\n failure. \"test_must_fail grep string output\" is unnecessary, as\n we are not making sure the system binaries do not dump core or\n anything like that.\n \n Signed-off-by: Junio C Hamano \n"},{"id":"219408","messageId":"82E212D3F25A4ABA923D1D81684F6578@PhilipOakley","threadId":"33962","inReplyTo":"7v1u8h7gac.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] t/README: test_must_fail is for testing Git","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-06-04T21:12:06Z","receivedAt":"2013-06-04T21:12:06Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Tuesday, June 04, 2013 9:49 PM\n> \"Philip Oakley\" writes:\n>\n>> From: \"Junio C Hamano\" \n>> Sent: Tuesday, June 04, 2013 5:50 PM\n>>> When a test wants to make sure there is no in an output\n>>> file, we should just say \"! grep string output\";\n>>\n>> Small nit: It took me two readings of the commit message to correctly\n>> parse this break point. The flowing together of the two parts with \n>> the\n>> semicolon fooled me. Separate them?\n>>\n>>> \"test_must_fail\"\n>>> is there only to test Git command and catch unusual deaths we know\n>>> about (e.g. segv) as an error, not as an expected failure.\n>\n> Thanks. Does this read better?\n\nYes. Thanks.\n\n>\n> t/README: test_must_fail is for testing Git\n>\n> When a test wants to make sure there is no in an output\n> file, we should just say \"! grep string output\".\n>\n> \"test_must_fail\" is there only to test Git command and catch \n> unusual\n> deaths we know about (e.g. segv) as an error, not as an expected\n> failure. \"test_must_fail grep string output\" is unnecessary, as\n> we are not making sure the system binaries do not dump core or\n> anything like that.\n>\n> Signed-off-by: Junio C Hamano \n> --\n\nPhilip \n"}]}