{"thread":{"id":"21436","subject":"Re: Bug#553296: gitignore broken completely","startedAt":"2009-10-30T17:38:38Z","lastAt":"2009-10-30T21:41:13Z","messageCount":13,"participants":["Jeff King","Klaus Ethgen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"126398","messageId":"20091030173838.GB18583@coredump.intra.peff.net","threadId":"21436","inReplyTo":"20091030165903.GA10671@ikki.ethgen.de","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-30T17:38:38Z","receivedAt":"2009-10-30T17:38:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[cc'ing git@vger and quoting excessively to give those readers context]\n\nOn Fri, Oct 30, 2009 at 05:59:03PM +0100, Klaus Ethgen wrote:\n\n> Am Fr den 30. Okt 2009 um 17:28 schrieb Gerrit Pape:\n> > > The most recent git in debian has a broken ignore handling. Let me\n> > > show\n> > > it on a example:\n> > >  > mkdir gittest\n> > >  > cd gittest\n> > >  > git init\n> > >  > touch a\n> > >  > git add a\n> > >  > git commit -m commit\n> > >  > git ls-files -i --exclude-standard\n> > > \n> > > The last command will show the file a (as it would show every file as\n> > > being ignored, every which is in the index!). But that command should\n> > > show nothing at that point.\n> > \n> > Hi Klaus, it looks like upstream did that on purpose\n> > \n> >  http://git.kernel.org/?p=git/git.git;a=commit;h=b5227d80\n> > \n> > $ git describe --contains b5227d80\n> > v1.6.5.2~2^2^2\n\nIt was not exactly on purpose. The point of that change was that \"git\nls-files\" should also show things mentioned in the .gitignore, because\n.gitignore has nothing to do whatsoever with tracked files.\n\nBut I simply forgot about \"git ls-files -i\", so changing it was an\nunintended side effect (and sadly, we don't seem to have any regression\ntests for it).\n\n> That makes the whole sense of -i ad absurdum (I do not know how to tell\n> \"ad absurdum\" in english). With that patch there is no way anymore to\n> see if some ignored files are accidentally committed.\n\nYes, with the current code \"-i\" serves no purpose unless you are using\n\"-o\".\n\n> I have to use git often as frontend for that broken design (svn). So to\n> hold the ignores up2date I use \"git svn show-ignore > .gitignore\" But\n> many, many repositories have broken ignores so I have to check it with\n> \"git ls-files -i --exclude-standard\" to see if there is accidentally\n> ignored files. Well, that patch makes that impossible at all!\n\nJust to be clear: nothing is actually broken about ignores that cover\ntracked files. Ignores are (and have been since long before this patch)\npurely about untracked files. So there is no problem at all with:\n\n  $ echo content >foo\n  $ git add foo\n  $ echo foo >.gitignore\n  $ git commit\n\nThe _only_ thing that respected such ignores was \"git ls-files\", and the\npoint of the patch in question was to fix that.\n\n> So I think, this patch is a bug at all!\n> \n> I add Jeff (and Junio as he did the commit) to the Cc. @Jeff and or\n> Junio: could you please revoke that patch?\n\nI am not sure simply reverting is the best choice; the patch does do\nsomething useful. And while it strictly breaks backwards compatibility\non the output without \"-i\", the old behavior was considered a bug. But\nthe \"-i\" behavior is useless now, so we need to figure out how to\nproceed. We can:\n\n  1. Revert and accept that the behavior is historical. Callers need to\n     work around it by dropping --exclude* when invoking ls-files.\n\n  2. Declare \"-i\" useless, deprecate and/or remove. Obviously this is\n     also breaking existing behavior, but again, I don't think that\n     using \"-i\" actually accomplishes anything.\n\n  3. Revert for now, and then reinstate the patch during a major version\n     bump when we are declaring some compatibility breakages.\n\n  4. Re-work \"-i\" to show tracked but ignored files, but still show all\n     files when \"-i\" is not given at all.\n\nI think (4) preserves the benefit of the patch in question, but still\nallows your usage (\"git ls-files -i --exclude-standard\"). I do question\nwhether that usage is worth supporting. Certainly I wouldn't implement\nit if I were writing git-ls-files from scratch today, but we do in\ngeneral try to maintain backwards compatibility, especially for plumbing\nlike ls-files.\n\nJunio, what do you want to do?\n\n-Peff\n"},{"id":"126406","messageId":"20091030182331.GC10671@ikki.ethgen.de","threadId":"21436","inReplyTo":"20091030173838.GB18583@coredump.intra.peff.net","subject":"Bug#553296: gitignore broken completely","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.de","sentAt":"2009-10-30T18:23:31Z","receivedAt":"2009-10-30T18:23:31Z","isPatch":false,"sender":{"key":"klaus@ethgen.de","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nAm Fr den 30. Okt 2009 um 18:38 schrieb Jeff King:\n> It was not exactly on purpose. The point of that change was that \"git\n> ls-files\" should also show things mentioned in the .gitignore, because\n> .gitignore has nothing to do whatsoever with tracked files.\n\n(Mostly) true. It has when sending such patches that adds a ignored\nfile, to some other.\n\n> But I simply forgot about \"git ls-files -i\", so changing it was an\n> unintended side effect (and sadly, we don't seem to have any regression\n> tests for it).\n\nCould happen. No Problem with that as such.\n\n> > That makes the whole sense of -i ad absurdum (I do not know how to tell\n> > \"ad absurdum\" in english). With that patch there is no way anymore to\n> > see if some ignored files are accidentally committed.\n> \n> Yes, with the current code \"-i\" serves no purpose unless you are using\n> \"-o\".\n\nBut this is an other use case.\n\n> > I have to use git often as frontend for that broken design (svn). So to\n> > hold the ignores up2date I use \"git svn show-ignore > .gitignore\" But\n> > many, many repositories have broken ignores so I have to check it with\n> > \"git ls-files -i --exclude-standard\" to see if there is accidentally\n> > ignored files. Well, that patch makes that impossible at all!\n> \n> Just to be clear: nothing is actually broken about ignores that cover\n> tracked files. Ignores are (and have been since long before this patch)\n> purely about untracked files. So there is no problem at all with:\n\nSee my comment above.\n\n> The _only_ thing that respected such ignores was \"git ls-files\", and the\n> point of the patch in question was to fix that.\n\nWell ls-files is used to see such broken files. (Another example is if\nyou accidentally add a file which you (later) decide to be ignored. You\nwill have no change to find that files at all anymore.) With the patch\nthat use case of ls-files has been gone without a replacement.\n\n> > So I think, this patch is a bug at all!\n> > \n> > I add Jeff (and Junio as he did the commit) to the Cc. @Jeff and or\n> > Junio: could you please revoke that patch?\n> \n> I am not sure simply reverting is the best choice; the patch does do\n> something useful. And while it strictly breaks backwards compatibility\n> on the output without \"-i\", the old behavior was considered a bug. But\n> the \"-i\" behavior is useless now, so we need to figure out how to\n> proceed. We can:\n> \n>   1. Revert and accept that the behavior is historical. Callers need to\n>      work around it by dropping --exclude* when invoking ls-files.\n> \n>   2. Declare \"-i\" useless, deprecate and/or remove. Obviously this is\n>      also breaking existing behavior, but again, I don't think that\n>      using \"-i\" actually accomplishes anything.\n> \n>   3. Revert for now, and then reinstate the patch during a major version\n>      bump when we are declaring some compatibility breakages.\n> \n>   4. Re-work \"-i\" to show tracked but ignored files, but still show all\n>      files when \"-i\" is not given at all.\n\nI have two more options:\n\n   5. Revert the patch and rework it to have a option to ignore or\n      respect the excluded files (Such as --use-excludes for example) or\n      respect them anyway if a --exclude* option is given on command\n      line.\n\n   6. Revert the patch and rework it so that it will only have effect if\n      there is no -i option on the command line. (That is similiar to a\n      mix of 3 and 4.)\n\nI have nothing against the patch as such. But in the current form it\nbreaks at least one frequent used use case of ls-files.\n\n> I think (4) preserves the benefit of the patch in question, but still\n> allows your usage (\"git ls-files -i --exclude-standard\"). I do question\n> whether that usage is worth supporting. Certainly I wouldn't implement\n> it if I were writing git-ls-files from scratch today,\n\nWell I had to search explicit for this use case as I had several\nproblems with ignored files in combination with svn. So I would. (if I\nknow the code good enough. And this problem to list such files did made\nenough pain to me that I would go into the code to get it implemented.)\n\nRegards\n   Klaus\n- -- \nKlaus Ethgen                            http://www.ethgen.de/\npub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>\nFingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.9 (GNU/Linux)\n\niQEVAwUBSusvI5+OKpjRpO3lAQqMhQgAnM7w+VqvUB+zFCJj8sCqO6QgcI+oup1z\ndMwsv+5QU+S5UH7xdm/L6AhFJEsWsbpHzytVg7Rv3wCp8OzFiXmnjfUw+3JEvuLJ\n+ggWHvFeKkTReDaRY00dafAQCP/8h0Yar6hVmXfdqGeiOnK0LeN5OXx0T3K51U/2\nr8YOeNPZOzbaITcRaeIi5ghAEpyAgdqEw++f8h1xCRGo6DyncUIoexmFSG0pZS8q\ntsyksW7q02LscTEp6PinQa7jhUN0xWJFTvpuCBWlfNgNTTffWt1xDjXTebwRKsYR\ncT1ygEiI2+aZfrE47Fn91G9I+JjF5KYo7jt5UFNFlck9YsEKGPf22g==\n=2ZcU\n-----END PGP SIGNATURE-----\n"},{"id":"126405","messageId":"20091030184155.GC19901@coredump.intra.peff.net","threadId":"21436","inReplyTo":"20091030182331.GC10671@ikki.ethgen.de","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-30T18:41:55Z","receivedAt":"2009-10-30T18:41:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 30, 2009 at 07:23:31PM +0100, Klaus Ethgen wrote:\n\n> Well ls-files is used to see such broken files. (Another example is if\n> you accidentally add a file which you (later) decide to be ignored. You\n> will have no change to find that files at all anymore.) With the patch\n> that use case of ls-files has been gone without a replacement.\n\nI think your reasoning is a little bit circular. They are not actually\nbroken with respect to git. But they might represent an error on the\npart of the programmer, and one which they would want to investigate.\nYou could also catch it by looking at diffs (\"why is this file in my\ndiff, it is supposed to be ignored\"), but I am not opposed to accessing\nthe information via git-ls-files (and I think you are right that the\nquery cannot be easily done any other way).\n\n> I have two more options:\n> \n>    5. Revert the patch and rework it to have a option to ignore or\n>       respect the excluded files (Such as --use-excludes for example) or\n>       respect them anyway if a --exclude* option is given on command\n>       line.\n\nI think that is basically equivalent to (1). There is already a way for\ncallers to avoid the bug, which is not to provide --exclude* at all. So\nyou are already setting that one bit of information in whether or not\nyou provide any excludes.\n\n>    6. Revert the patch and rework it so that it will only have effect if\n>       there is no -i option on the command line. (That is similiar to a\n>       mix of 3 and 4.)\n\nYeah, that would actually be the least invasive change, and would keep\n\"-i\" just as it is. If we do anything except a simple, I think your (6)\nmakes the most sense.\n\nLet me see if I can make a patch.\n\n-Peff\n"},{"id":"126409","messageId":"20091030190552.GA3528@coredump.intra.peff.net","threadId":"21436","inReplyTo":"20091030184155.GC19901@coredump.intra.peff.net","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-30T19:05:52Z","receivedAt":"2009-10-30T19:05:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 30, 2009 at 02:41:55PM -0400, Jeff King wrote:\n\n> >    6. Revert the patch and rework it so that it will only have effect if\n> >       there is no -i option on the command line. (That is similiar to a\n> >       mix of 3 and 4.)\n> \n> Yeah, that would actually be the least invasive change, and would keep\n> \"-i\" just as it is. If we do anything except a simple, I think your (6)\n> makes the most sense.\n> \n> Let me see if I can make a patch.\n\nHere it is. I think this is the right thing to do. Junio?\n\n-- >8 --\nSubject: [PATCH] ls-files: unbreak \"ls-files -i\"\n\nCommit b5227d8 changed the behavior of \"ls-files\" with\nrespect to includes, but accidentally broke the \"-i\" option\nThe original behavior was:\n\n  1. if no \"-i\" is given, cull all results according to --exclude*\n  2. if \"-i\" is given, show the inverse of (1)\n\nThe broken behavior was:\n\n  1. if no \"-i\" is given:\n     a. for \"-o\", cull results according to --exclude*\n     b. for index files, always show all\n  2. if \"-i\" is given:\n     a. for \"-o\", shows the inverse of (1a)\n     b. for index files, always show all\n\nThe fixed behavior keeps the new (1b) behavior introduced\nby b5227d8, but fixes the (2b) behavior to show only ignored\nfiles, not all files.\n\nThis patch also tweaks the documentation. The original text\nwas somewhat obscure in the first place, but it is also now\ninaccurate (the relationship between (1b) and (2b) is not\nquite a \"reverse\").\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n Documentation/git-ls-files.txt |    6 ++++--\n builtin-ls-files.c             |    8 ++++++++\n t/t3003-ls-files-exclude.sh    |    8 ++++++++\n 3 files changed, 20 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt\nindex 021066e..625723e 100644\n--- a/Documentation/git-ls-files.txt\n+++ b/Documentation/git-ls-files.txt\n@@ -48,8 +48,10 @@ OPTIONS\n \n -i::\n --ignored::\n-\tShow ignored files in the output.\n-\tNote that this also reverses any exclude list present.\n+\tShow only ignored files in the output. When showing files in the\n+\tindex, print only those matched by an exclude pattern. When\n+\tshowing \"other\" files, show only those matched by an exclude\n+\tpattern.\n \n -s::\n --stage::\ndiff --git a/builtin-ls-files.c b/builtin-ls-files.c\nindex c5c0407..c9a03e5 100644\n--- a/builtin-ls-files.c\n+++ b/builtin-ls-files.c\n@@ -170,6 +170,10 @@ static void show_files(struct dir_struct *dir, const char *prefix)\n \tif (show_cached | show_stage) {\n \t\tfor (i = 0; i < active_nr; i++) {\n \t\t\tstruct cache_entry *ce = active_cache[i];\n+\t\t\tint dtype = ce_to_dtype(ce);\n+\t\t\tif (dir->flags & DIR_SHOW_IGNORED &&\n+\t\t\t    !excluded(dir, ce->name, &dtype))\n+\t\t\t\tcontinue;\n \t\t\tif (show_unmerged && !ce_stage(ce))\n \t\t\t\tcontinue;\n \t\t\tif (ce->ce_flags & CE_UPDATE)\n@@ -182,6 +186,10 @@ static void show_files(struct dir_struct *dir, const char *prefix)\n \t\t\tstruct cache_entry *ce = active_cache[i];\n \t\t\tstruct stat st;\n \t\t\tint err;\n+\t\t\tint dtype = ce_to_dtype(ce);\n+\t\t\tif (dir->flags & DIR_SHOW_IGNORED &&\n+\t\t\t    !excluded(dir, ce->name, &dtype))\n+\t\t\t\tcontinue;\n \t\t\tif (ce->ce_flags & CE_UPDATE)\n \t\t\t\tcontinue;\n \t\t\terr = lstat(ce->name, &st);\ndiff --git a/t/t3003-ls-files-exclude.sh b/t/t3003-ls-files-exclude.sh\nindex fc1e379..d5ec333 100755\n--- a/t/t3003-ls-files-exclude.sh\n+++ b/t/t3003-ls-files-exclude.sh\n@@ -29,4 +29,12 @@ test_expect_success 'add file to gitignore' '\n '\n check_all_output\n \n+test_expect_success 'ls-files -i lists only tracked-but-ignored files' '\n+\techo content >other-file &&\n+\tgit add other-file &&\n+\techo file >expect &&\n+\tgit ls-files -i --exclude-standard >output &&\n+\ttest_cmp expect output\n+'\n+\n test_done\n-- \n1.6.5.2.224.g22719.dirty\n"},{"id":"126416","messageId":"7vaaz8lleg.fsf@alter.siamese.dyndns.org","threadId":"21436","inReplyTo":"20091030173838.GB18583@coredump.intra.peff.net","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-30T19:41:27Z","receivedAt":"2009-10-30T19:41:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I am not sure simply reverting is the best choice; the patch does do\n> something useful. And while it strictly breaks backwards compatibility\n> on the output without \"-i\", the old behavior was considered a bug. But\n> the \"-i\" behavior is useless now, so we need to figure out how to\n> proceed. We can:\n>\n>   1. Revert and accept that the behavior is historical. Callers need to\n>      work around it by dropping --exclude* when invoking ls-files.\n>\n>   2. Declare \"-i\" useless, deprecate and/or remove. Obviously this is\n>      also breaking existing behavior, but again, I don't think that\n>      using \"-i\" actually accomplishes anything.\n>\n>   3. Revert for now, and then reinstate the patch during a major version\n>      bump when we are declaring some compatibility breakages.\n>\n>   4. Re-work \"-i\" to show tracked but ignored files, but still show all\n>      files when \"-i\" is not given at all.\n>\n> I think (4) preserves the benefit of the patch in question, but still\n> allows your usage (\"git ls-files -i --exclude-standard\"). I do question\n> whether that usage is worth supporting. Certainly I wouldn't implement\n> it if I were writing git-ls-files from scratch today, but we do in\n> general try to maintain backwards compatibility, especially for plumbing\n> like ls-files.\n>\n> Junio, what do you want to do?\n\nI've never understood the use of \"ls-files -i\" without -o, so in that\nsense, I have done 2. myself already long time ago.\n\nIn other words, I do not really care that much, and the choice would be\nbetween \"0. do not do anything---the patch in question was a bugfix for\nlongstanding insanity\" and your \"4. -i without -o didn't make much sense\nbut now it does and here is the new meaning\".\n"},{"id":"126417","messageId":"20091030194333.GA4551@coredump.intra.peff.net","threadId":"21436","inReplyTo":"7vaaz8lleg.fsf@alter.siamese.dyndns.org","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-30T19:43:33Z","receivedAt":"2009-10-30T19:43:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 30, 2009 at 12:41:27PM -0700, Junio C Hamano wrote:\n\n> I've never understood the use of \"ls-files -i\" without -o, so in that\n> sense, I have done 2. myself already long time ago.\n> \n> In other words, I do not really care that much, and the choice would be\n> between \"0. do not do anything---the patch in question was a bugfix for\n> longstanding insanity\" and your \"4. -i without -o didn't make much sense\n> but now it does and here is the new meaning\".\n\nOK, I think the patch I sent elsewhere in the thread should be applied,\nthen, as it should make you, me, and Klaus happy.\n\n-Peff\n"},{"id":"126419","messageId":"7vvdhwk6dq.fsf@alter.siamese.dyndns.org","threadId":"21436","inReplyTo":"20091030190552.GA3528@coredump.intra.peff.net","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-30T19:51:13Z","receivedAt":"2009-10-30T19:51:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Oct 30, 2009 at 02:41:55PM -0400, Jeff King wrote:\n>\n>> >    6. Revert the patch and rework it so that it will only have effect if\n>> >       there is no -i option on the command line. (That is similiar to a\n>> >       mix of 3 and 4.)\n>> \n>> Yeah, that would actually be the least invasive change, and would keep\n>> \"-i\" just as it is. If we do anything except a simple, I think your (6)\n>> makes the most sense.\n>> \n>> Let me see if I can make a patch.\n>\n> Here it is. I think this is the right thing to do. Junio?\n\nI am not sure; my head spins when I see \"tracked but ignored\" (you have\na new one in the test) which is quite a bogus concept.\n\nDoes it mean \"tracked but would be ignored if it weren't---perhaps it was\nadded by mistake?\"?\n"},{"id":"126420","messageId":"20091030195216.GA27135@coredump.intra.peff.net","threadId":"21436","inReplyTo":"7vvdhwk6dq.fsf@alter.siamese.dyndns.org","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-30T19:52:16Z","receivedAt":"2009-10-30T19:52:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 30, 2009 at 12:51:13PM -0700, Junio C Hamano wrote:\n\n> > Here it is. I think this is the right thing to do. Junio?\n> \n> I am not sure; my head spins when I see \"tracked but ignored\" (you have\n> a new one in the test) which is quite a bogus concept.\n> \n> Does it mean \"tracked but would be ignored if it weren't---perhaps it was\n> added by mistake?\"?\n\nYes, that is exactly what it means.\n\n-Peff\n"},{"id":"126421","messageId":"20091030200148.GD10671@ikki.ethgen.de","threadId":"21436","inReplyTo":"20091030194333.GA4551@coredump.intra.peff.net","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.de","sentAt":"2009-10-30T20:01:48Z","receivedAt":"2009-10-30T20:01:48Z","isPatch":false,"sender":{"key":"klaus@ethgen.de","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nHi Jeff,\n\nAm Fr den 30. Okt 2009 um 20:05 schrieb Jeff King:\n> On Fri, Oct 30, 2009 at 02:41:55PM -0400, Jeff King wrote:\n> \n> > >    6. Revert the patch and rework it so that it will only have effect if\n> > >       there is no -i option on the command line. (That is similiar to a\n> > >       mix of 3 and 4.)\n> > \n> > Yeah, that would actually be the least invasive change, and would keep\n> > \"-i\" just as it is. If we do anything except a simple, I think your (6)\n> > makes the most sense.\n\nOk.\n\n> > Let me see if I can make a patch.\n\nFine, thanks.\n\n> -\tShow ignored files in the output.\n> -\tNote that this also reverses any exclude list present.\n> +\tShow only ignored files in the output. When showing files in the\n> +\tindex, print only those matched by an exclude pattern. When\n> +\tshowing \"other\" files, show only those matched by an exclude\n> +\tpattern.\n\nHmmm... I do not see that much difference. But that might be justified\nby my bad English.\n\n> --- a/t/t3003-ls-files-exclude.sh\n> +++ b/t/t3003-ls-files-exclude.sh\n> @@ -29,4 +29,12 @@ test_expect_success 'add file to gitignore' '\n>  '\n>  check_all_output\n>  \n> +test_expect_success 'ls-files -i lists only tracked-but-ignored files' '\n> +\techo content >other-file &&\n> +\tgit add other-file &&\n> +\techo file >expect &&\n> +\tgit ls-files -i --exclude-standard >output &&\n> +\ttest_cmp expect output\n> +'\n> +\n>  test_done\n\nDo that fit? shouldn't it be \"test_cmp other-file output\"? \"git ls-files\n- -i --exclude-standard\" should show the files in the index that are also\nin the exclude list. And you only add other-file to the index. And\nshouldn't there be also a \"echo other-file > .gitignore\"?\n\nRegards\n   Klaus\n- -- \nKlaus Ethgen                            http://www.ethgen.de/\npub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>\nFingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.9 (GNU/Linux)\n\niQEVAwUBSutGLJ+OKpjRpO3lAQqmZwgAi7DqPorAdp0dZtgMpgzCsrWTJx5xb/dv\nvoQ4K5pYmxG1PgLb8zY7ywIvcG36uakCGvwgFQxsLzSgg0hRO1UsQ8XFVqSPp62X\nevsZ/On5LYHY3xz+Fl0cPM5oomtqY+ZmHAd5syj4oh6hSHM8J93RuQzGEfMshtrQ\nNUfAbAVmjuA5d4Cl/SLNUvoLE6M6O3YGkCGKXA9aPQcker6W+nODExJgTqyh4RHK\nATfbPC6+VJGUPfjVGmrqHVW8LOb/wP7grEBMaHvGpP/ysh4FHjy6HtXLhyPSRES/\nKpsMG5g0dF0dbS0qBgrIck+6cifiHNlAbxc5LF7tydFBMnRAmjDyeA==\n=7JTn\n-----END PGP SIGNATURE-----\n"},{"id":"126422","messageId":"20091030200500.GA24831@coredump.intra.peff.net","threadId":"21436","inReplyTo":"20091030200148.GD10671@ikki.ethgen.de","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-30T20:05:00Z","receivedAt":"2009-10-30T20:05:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 30, 2009 at 09:01:48PM +0100, Klaus Ethgen wrote:\n\n> > +test_expect_success 'ls-files -i lists only tracked-but-ignored files' '\n> > +\techo content >other-file &&\n> > +\tgit add other-file &&\n> > +\techo file >expect &&\n> > +\tgit ls-files -i --exclude-standard >output &&\n> > +\ttest_cmp expect output\n> > +'\n> > +\n> >  test_done\n> \n> Do that fit? shouldn't it be \"test_cmp other-file output\"? \"git ls-files\n> -i --exclude-standard\" should show the files in the index that are also\n> in the exclude list. And you only add other-file to the index. And\n> shouldn't there be also a \"echo other-file > .gitignore\"?\n\nNo, because it is building on the previous tests. The point of the test\nis:\n\n  - we already have 'file' tracked and in gitignore (from previous\n    tests in the series)\n  - we add other-file to have some other file which is tracked but not\n    in gitignore\n  - we check the output of \"ls-files -i\" to make sure that \"file\" is\n    there, but \"other-file\" is not\n\n-Peff\n"},{"id":"126423","messageId":"20091030200508.GE10671@ikki.ethgen.de","threadId":"21436","inReplyTo":"7vvdhwk6dq.fsf@alter.siamese.dyndns.org","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.de","sentAt":"2009-10-30T20:05:08Z","receivedAt":"2009-10-30T20:05:08Z","isPatch":false,"sender":{"key":"klaus@ethgen.de","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nHi Junio,\n\nAm Fr den 30. Okt 2009 um 20:51 schrieb Junio C Hamano:\n> I am not sure; my head spins when I see \"tracked but ignored\" (you have\n> a new one in the test) which is quite a bogus concept.\n> \n> Does it mean \"tracked but would be ignored if it weren't---perhaps it was\n> added by mistake?\"?\n\nRight. Exact. Sorry if my arguing was a bit misunderstandable. (My\nspellchecker do not know \"misunderstandable\", so I hope it is ok; I am\nfrom Germany, we like long words. ;-)\n\nRegards\n   Klaus\n- -- \nKlaus Ethgen                            http://www.ethgen.de/\npub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>\nFingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.9 (GNU/Linux)\n\niQEVAwUBSutG9J+OKpjRpO3lAQqBCQf+MWXaVdCeD7bT/dTCEQ8WfVKwISR6qNCP\nwttV5oHnMp/f1mDWqhwYc4OUeOcLtkcV6pNf4oCMLY5v6zuvnLDgGB/8XW3l6JgZ\nY7m0UoSRu0s5Hux+VX/+CLwJ1cylstkwx3yOxcZ5VSXAgDlRIrt7LpwCsh/7lMSO\nn5KUHw3/RodTwomxXUSRTQqU+SQMOUJrUvYR1EE9zR0YQkDKYqhulhUH+uirLaBQ\n0rfJB7sTRqFfv2kHMLzO8t+jfco39cOZWTxlE1QBN1+k7aTZIJD2d79atfY7NLo0\n2kCfcJXRurQ2rSpjUAbDVBo8JvkclnEnVLZP+s5kuwzej0hy4D2ocg==\n=sN6Y\n-----END PGP SIGNATURE-----\n"},{"id":"126425","messageId":"20091030200824.GF10671@ikki.ethgen.de","threadId":"21436","inReplyTo":"20091030200500.GA24831@coredump.intra.peff.net","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Klaus Ethgen","fromEmail":"klaus@ethgen.de","sentAt":"2009-10-30T20:08:25Z","receivedAt":"2009-10-30T20:08:25Z","isPatch":false,"sender":{"key":"klaus@ethgen.de","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nAm Fr den 30. Okt 2009 um 21:05 schrieb Jeff King:\n> > > +\ttest_cmp expect output\n[...]\n> No, because it is building on the previous tests. The point of the test\n> is:\n> \n>   - we already have 'file' tracked and in gitignore (from previous\n>     tests in the series)\n>   - we add other-file to have some other file which is tracked but not\n>     in gitignore\n>   - we check the output of \"ls-files -i\" to make sure that \"file\" is\n>     there, but \"other-file\" is not\n\nAha, now I get it, the \"test_cmp\" do check the _content_ of the file\nexpect and not the file expect itself.\n\nRegards\n   Klaus\n\nPs. Uh, oh, maybe I should truncate the Cc ;-) Ok, hoping that is ok so\ntoo.\n- -- \nKlaus Ethgen                            http://www.ethgen.de/\npub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>\nFingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.9 (GNU/Linux)\n\niQEVAwUBSutHuJ+OKpjRpO3lAQoL2gf8DixaPjnEkLhOZUK4VVsXU7zJ/bB3qWnP\n71yq3sPA3Fi9Bq51d06YnxAQe/WqJWnOtSzgw8V5QquTaEM5Lqp6bgY49jynj6mf\nwRSL+L4y+jpuerIQ/SK3yVcNw837URfQNDGFPNVSJAwGYfeMWiYh52fqwPVxO37p\nwsNryc2CqpviaiqK12XwyEn7NHxPROdIRm0K8uezsw1fzWUcx4hN8IVbl8i8z0ss\nbrgyuMsT+R0GnazT/IndLkGniuBFBF2pdyD5uYv/lqF+q8TOC+iQzhxuA0cj/EC6\ny5FuVCOTLA938bmclvhnl1hfzg4+6c5xoqqtWI2DzJoXkm2zJpvlLQ==\n=VEYC\n-----END PGP SIGNATURE-----\n"},{"id":"126435","messageId":"7v7huck1ae.fsf@alter.siamese.dyndns.org","threadId":"21436","inReplyTo":"20091030194333.GA4551@coredump.intra.peff.net","subject":"Re: Bug#553296: gitignore broken completely","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-30T21:41:13Z","receivedAt":"2009-10-30T21:41:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Oct 30, 2009 at 12:41:27PM -0700, Junio C Hamano wrote:\n>\n>> I've never understood the use of \"ls-files -i\" without -o, so in that\n>> sense, I have done 2. myself already long time ago.\n>> \n>> In other words, I do not really care that much, and the choice would be\n>> between \"0. do not do anything---the patch in question was a bugfix for\n>> longstanding insanity\" and your \"4. -i without -o didn't make much sense\n>> but now it does and here is the new meaning\".\n>\n> OK, I think the patch I sent elsewhere in the thread should be applied,\n> then, as it should make you, me, and Klaus happy.\n\nThanks; will queue on top of b5227d8.\n"}]}