Re: Bug#553296: gitignore broken completely

Re: Bug#553296: gitignore broken completely

[Jeff King]

[cc'ing git@vger and quoting excessively to give those readers context]

On Fri, Oct 30, 2009 at 05:59:03PM +0100, Klaus Ethgen wrote:

> Am Fr den 30. Okt 2009 um 17:28 schrieb Gerrit Pape:
> > > The most recent git in debian has a broken ignore handling. Let me
> > > show
> > > it on a example:
> > >  > mkdir gittest
> > >  > cd gittest
> > >  > git init
> > >  > touch a
> > >  > git add a
> > >  > git commit -m commit
> > >  > git ls-files -i --exclude-standard
> > > 
> > > The last command will show the file a (as it would show every file as
> > > being ignored, every which is in the index!). But that command should
> > > show nothing at that point.
> > 
> > Hi Klaus, it looks like upstream did that on purpose
> > 
> >  http://git.kernel.org/?p=git/git.git;a=commit;h=b5227d80
> > 
> > $ git describe --contains b5227d80
> > v1.6.5.2~2^2^2

It was not exactly on purpose. The point of that change was that "git
ls-files" should also show things mentioned in the .gitignore, because
.gitignore has nothing to do whatsoever with tracked files.

But I simply forgot about "git ls-files -i", so changing it was an
unintended side effect (and sadly, we don't seem to have any regression
tests for it).

> That makes the whole sense of -i ad absurdum (I do not know how to tell
> "ad absurdum" in english). With that patch there is no way anymore to
> see if some ignored files are accidentally committed.

Yes, with the current code "-i" serves no purpose unless you are using
"-o".

> I have to use git often as frontend for that broken design (svn). So to
> hold the ignores up2date I use "git svn show-ignore > .gitignore" But
> many, many repositories have broken ignores so I have to check it with
> "git ls-files -i --exclude-standard" to see if there is accidentally
> ignored files. Well, that patch makes that impossible at all!

Just to be clear: nothing is actually broken about ignores that cover
tracked files. Ignores are (and have been since long before this patch)
purely about untracked files. So there is no problem at all with:

  $ echo content >foo
  $ git add foo
  $ echo foo >.gitignore
  $ git commit

The _only_ thing that respected such ignores was "git ls-files", and the
point of the patch in question was to fix that.

> So I think, this patch is a bug at all!
> 
> I add Jeff (and Junio as he did the commit) to the Cc. @Jeff and or
> Junio: could you please revoke that patch?

I am not sure simply reverting is the best choice; the patch does do
something useful. And while it strictly breaks backwards compatibility
on the output without "-i", the old behavior was considered a bug. But
the "-i" behavior is useless now, so we need to figure out how to
proceed. We can:

  1. Revert and accept that the behavior is historical. Callers need to
     work around it by dropping --exclude* when invoking ls-files.

  2. Declare "-i" useless, deprecate and/or remove. Obviously this is
     also breaking existing behavior, but again, I don't think that
     using "-i" actually accomplishes anything.

  3. Revert for now, and then reinstate the patch during a major version
     bump when we are declaring some compatibility breakages.

  4. Re-work "-i" to show tracked but ignored files, but still show all
     files when "-i" is not given at all.

I think (4) preserves the benefit of the patch in question, but still
allows your usage ("git ls-files -i --exclude-standard"). I do question
whether that usage is worth supporting. Certainly I wouldn't implement
it if I were writing git-ls-files from scratch today, but we do in
general try to maintain backwards compatibility, especially for plumbing
like ls-files.

Junio, what do you want to do?

-Peff

Bug#553296: gitignore broken completely

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Fr den 30. Okt 2009 um 18:38 schrieb Jeff King:
> It was not exactly on purpose. The point of that change was that "git
> ls-files" should also show things mentioned in the .gitignore, because
> .gitignore has nothing to do whatsoever with tracked files.

(Mostly) true. It has when sending such patches that adds a ignored
file, to some other.

> But I simply forgot about "git ls-files -i", so changing it was an
> unintended side effect (and sadly, we don't seem to have any regression
> tests for it).

Could happen. No Problem with that as such.

> > That makes the whole sense of -i ad absurdum (I do not know how to tell
> > "ad absurdum" in english). With that patch there is no way anymore to
> > see if some ignored files are accidentally committed.
> 
> Yes, with the current code "-i" serves no purpose unless you are using
> "-o".

But this is an other use case.

> > I have to use git often as frontend for that broken design (svn). So to
> > hold the ignores up2date I use "git svn show-ignore > .gitignore" But
> > many, many repositories have broken ignores so I have to check it with
> > "git ls-files -i --exclude-standard" to see if there is accidentally
> > ignored files. Well, that patch makes that impossible at all!
> 
> Just to be clear: nothing is actually broken about ignores that cover
> tracked files. Ignores are (and have been since long before this patch)
> purely about untracked files. So there is no problem at all with:

See my comment above.

> The _only_ thing that respected such ignores was "git ls-files", and the
> point of the patch in question was to fix that.

Well ls-files is used to see such broken files. (Another example is if
you accidentally add a file which you (later) decide to be ignored. You
will have no change to find that files at all anymore.) With the patch
that use case of ls-files has been gone without a replacement.

> > So I think, this patch is a bug at all!
> > 
> > I add Jeff (and Junio as he did the commit) to the Cc. @Jeff and or
> > Junio: could you please revoke that patch?
> 
> I am not sure simply reverting is the best choice; the patch does do
> something useful. And while it strictly breaks backwards compatibility
> on the output without "-i", the old behavior was considered a bug. But
> the "-i" behavior is useless now, so we need to figure out how to
> proceed. We can:
> 
>   1. Revert and accept that the behavior is historical. Callers need to
>      work around it by dropping --exclude* when invoking ls-files.
> 
>   2. Declare "-i" useless, deprecate and/or remove. Obviously this is
>      also breaking existing behavior, but again, I don't think that
>      using "-i" actually accomplishes anything.
> 
>   3. Revert for now, and then reinstate the patch during a major version
>      bump when we are declaring some compatibility breakages.
> 
>   4. Re-work "-i" to show tracked but ignored files, but still show all
>      files when "-i" is not given at all.

I have two more options:

   5. Revert the patch and rework it to have a option to ignore or
      respect the excluded files (Such as --use-excludes for example) or
      respect them anyway if a --exclude* option is given on command
      line.

   6. Revert the patch and rework it so that it will only have effect if
      there is no -i option on the command line. (That is similiar to a
      mix of 3 and 4.)

I have nothing against the patch as such. But in the current form it
breaks at least one frequent used use case of ls-files.

> I think (4) preserves the benefit of the patch in question, but still
> allows your usage ("git ls-files -i --exclude-standard"). I do question
> whether that usage is worth supporting. Certainly I wouldn't implement
> it if I were writing git-ls-files from scratch today,

Well I had to search explicit for this use case as I had several
problems with ignored files in combination with svn. So I would. (if I
know the code good enough. And this problem to list such files did made
enough pain to me that I would go into the code to get it implemented.)

Regards
   Klaus
- -- 
Klaus Ethgen                            http://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBSusvI5+OKpjRpO3lAQqMhQgAnM7w+VqvUB+zFCJj8sCqO6QgcI+oup1z
dMwsv+5QU+S5UH7xdm/L6AhFJEsWsbpHzytVg7Rv3wCp8OzFiXmnjfUw+3JEvuLJ
+ggWHvFeKkTReDaRY00dafAQCP/8h0Yar6hVmXfdqGeiOnK0LeN5OXx0T3K51U/2
r8YOeNPZOzbaITcRaeIi5ghAEpyAgdqEw++f8h1xCRGo6DyncUIoexmFSG0pZS8q
tsyksW7q02LscTEp6PinQa7jhUN0xWJFTvpuCBWlfNgNTTffWt1xDjXTebwRKsYR
cT1ygEiI2+aZfrE47Fn91G9I+JjF5KYo7jt5UFNFlck9YsEKGPf22g==
=2ZcU
-----END PGP SIGNATURE-----

Re: Bug#553296: gitignore broken completely

[Jeff King]

On Fri, Oct 30, 2009 at 07:23:31PM +0100, Klaus Ethgen wrote:

> Well ls-files is used to see such broken files. (Another example is if
> you accidentally add a file which you (later) decide to be ignored. You
> will have no change to find that files at all anymore.) With the patch
> that use case of ls-files has been gone without a replacement.

I think your reasoning is a little bit circular. They are not actually
broken with respect to git. But they might represent an error on the
part of the programmer, and one which they would want to investigate.
You could also catch it by looking at diffs ("why is this file in my
diff, it is supposed to be ignored"), but I am not opposed to accessing
the information via git-ls-files (and I think you are right that the
query cannot be easily done any other way).

> I have two more options:
> 
>    5. Revert the patch and rework it to have a option to ignore or
>       respect the excluded files (Such as --use-excludes for example) or
>       respect them anyway if a --exclude* option is given on command
>       line.

I think that is basically equivalent to (1). There is already a way for
callers to avoid the bug, which is not to provide --exclude* at all. So
you are already setting that one bit of information in whether or not
you provide any excludes.

>    6. Revert the patch and rework it so that it will only have effect if
>       there is no -i option on the command line. (That is similiar to a
>       mix of 3 and 4.)

Yeah, that would actually be the least invasive change, and would keep
"-i" just as it is. If we do anything except a simple, I think your (6)
makes the most sense.

Let me see if I can make a patch.

-Peff

Re: Bug#553296: gitignore broken completely

[Jeff King]

On Fri, Oct 30, 2009 at 02:41:55PM -0400, Jeff King wrote:

> >    6. Revert the patch and rework it so that it will only have effect if
> >       there is no -i option on the command line. (That is similiar to a
> >       mix of 3 and 4.)
> 
> Yeah, that would actually be the least invasive change, and would keep
> "-i" just as it is. If we do anything except a simple, I think your (6)
> makes the most sense.
> 
> Let me see if I can make a patch.

Here it is. I think this is the right thing to do. Junio?

-- >8 --
Subject: [PATCH] ls-files: unbreak "ls-files -i"

Commit b5227d8 changed the behavior of "ls-files" with
respect to includes, but accidentally broke the "-i" option
The original behavior was:

  1. if no "-i" is given, cull all results according to --exclude*
  2. if "-i" is given, show the inverse of (1)

The broken behavior was:

  1. if no "-i" is given:
     a. for "-o", cull results according to --exclude*
     b. for index files, always show all
  2. if "-i" is given:
     a. for "-o", shows the inverse of (1a)
     b. for index files, always show all

The fixed behavior keeps the new (1b) behavior introduced
by b5227d8, but fixes the (2b) behavior to show only ignored
files, not all files.

This patch also tweaks the documentation. The original text
was somewhat obscure in the first place, but it is also now
inaccurate (the relationship between (1b) and (2b) is not
quite a "reverse").

Signed-off-by: Jeff King <peff@peff.net>
---
 Documentation/git-ls-files.txt |    6 ++++--
 builtin-ls-files.c             |    8 ++++++++
 t/t3003-ls-files-exclude.sh    |    8 ++++++++
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 021066e..625723e 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -48,8 +48,10 @@ OPTIONS
 
 -i::
 --ignored::
-	Show ignored files in the output.
-	Note that this also reverses any exclude list present.
+	Show only ignored files in the output. When showing files in the
+	index, print only those matched by an exclude pattern. When
+	showing "other" files, show only those matched by an exclude
+	pattern.
 
 -s::
 --stage::
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index c5c0407..c9a03e5 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -170,6 +170,10 @@ static void show_files(struct dir_struct *dir, const char *prefix)
 	if (show_cached | show_stage) {
 		for (i = 0; i < active_nr; i++) {
 			struct cache_entry *ce = active_cache[i];
+			int dtype = ce_to_dtype(ce);
+			if (dir->flags & DIR_SHOW_IGNORED &&
+			    !excluded(dir, ce->name, &dtype))
+				continue;
 			if (show_unmerged && !ce_stage(ce))
 				continue;
 			if (ce->ce_flags & CE_UPDATE)
@@ -182,6 +186,10 @@ static void show_files(struct dir_struct *dir, const char *prefix)
 			struct cache_entry *ce = active_cache[i];
 			struct stat st;
 			int err;
+			int dtype = ce_to_dtype(ce);
+			if (dir->flags & DIR_SHOW_IGNORED &&
+			    !excluded(dir, ce->name, &dtype))
+				continue;
 			if (ce->ce_flags & CE_UPDATE)
 				continue;
 			err = lstat(ce->name, &st);
diff --git a/t/t3003-ls-files-exclude.sh b/t/t3003-ls-files-exclude.sh
index fc1e379..d5ec333 100755
--- a/t/t3003-ls-files-exclude.sh
+++ b/t/t3003-ls-files-exclude.sh
@@ -29,4 +29,12 @@ test_expect_success 'add file to gitignore' '
 '
 check_all_output
 
+test_expect_success 'ls-files -i lists only tracked-but-ignored files' '
+	echo content >other-file &&
+	git add other-file &&
+	echo file >expect &&
+	git ls-files -i --exclude-standard >output &&
+	test_cmp expect output
+'
+
 test_done
-- 
1.6.5.2.224.g22719.dirty

Re: Bug#553296: gitignore broken completely

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I am not sure simply reverting is the best choice; the patch does do
> something useful. And while it strictly breaks backwards compatibility
> on the output without "-i", the old behavior was considered a bug. But
> the "-i" behavior is useless now, so we need to figure out how to
> proceed. We can:
>
>   1. Revert and accept that the behavior is historical. Callers need to
>      work around it by dropping --exclude* when invoking ls-files.
>
>   2. Declare "-i" useless, deprecate and/or remove. Obviously this is
>      also breaking existing behavior, but again, I don't think that
>      using "-i" actually accomplishes anything.
>
>   3. Revert for now, and then reinstate the patch during a major version
>      bump when we are declaring some compatibility breakages.
>
>   4. Re-work "-i" to show tracked but ignored files, but still show all
>      files when "-i" is not given at all.
>
> I think (4) preserves the benefit of the patch in question, but still
> allows your usage ("git ls-files -i --exclude-standard"). I do question
> whether that usage is worth supporting. Certainly I wouldn't implement
> it if I were writing git-ls-files from scratch today, but we do in
> general try to maintain backwards compatibility, especially for plumbing
> like ls-files.
>
> Junio, what do you want to do?

I've never understood the use of "ls-files -i" without -o, so in that
sense, I have done 2. myself already long time ago.

In other words, I do not really care that much, and the choice would be
between "0. do not do anything---the patch in question was a bugfix for
longstanding insanity" and your "4. -i without -o didn't make much sense
but now it does and here is the new meaning".

Re: Bug#553296: gitignore broken completely

[Jeff King]

On Fri, Oct 30, 2009 at 12:41:27PM -0700, Junio C Hamano wrote:

> I've never understood the use of "ls-files -i" without -o, so in that
> sense, I have done 2. myself already long time ago.
> 
> In other words, I do not really care that much, and the choice would be
> between "0. do not do anything---the patch in question was a bugfix for
> longstanding insanity" and your "4. -i without -o didn't make much sense
> but now it does and here is the new meaning".

OK, I think the patch I sent elsewhere in the thread should be applied,
then, as it should make you, me, and Klaus happy.

-Peff

Re: Bug#553296: gitignore broken completely

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Fri, Oct 30, 2009 at 02:41:55PM -0400, Jeff King wrote:
>
>> >    6. Revert the patch and rework it so that it will only have effect if
>> >       there is no -i option on the command line. (That is similiar to a
>> >       mix of 3 and 4.)
>> 
>> Yeah, that would actually be the least invasive change, and would keep
>> "-i" just as it is. If we do anything except a simple, I think your (6)
>> makes the most sense.
>> 
>> Let me see if I can make a patch.
>
> Here it is. I think this is the right thing to do. Junio?

I am not sure; my head spins when I see "tracked but ignored" (you have
a new one in the test) which is quite a bogus concept.

Does it mean "tracked but would be ignored if it weren't---perhaps it was
added by mistake?"?

Re: Bug#553296: gitignore broken completely

[Jeff King]

On Fri, Oct 30, 2009 at 12:51:13PM -0700, Junio C Hamano wrote:

> > Here it is. I think this is the right thing to do. Junio?
> 
> I am not sure; my head spins when I see "tracked but ignored" (you have
> a new one in the test) which is quite a bogus concept.
> 
> Does it mean "tracked but would be ignored if it weren't---perhaps it was
> added by mistake?"?

Yes, that is exactly what it means.

-Peff

Re: Bug#553296: gitignore broken completely

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Jeff,

Am Fr den 30. Okt 2009 um 20:05 schrieb Jeff King:
> On Fri, Oct 30, 2009 at 02:41:55PM -0400, Jeff King wrote:
> 
> > >    6. Revert the patch and rework it so that it will only have effect if
> > >       there is no -i option on the command line. (That is similiar to a
> > >       mix of 3 and 4.)
> > 
> > Yeah, that would actually be the least invasive change, and would keep
> > "-i" just as it is. If we do anything except a simple, I think your (6)
> > makes the most sense.

Ok.

> > Let me see if I can make a patch.

Fine, thanks.

> -	Show ignored files in the output.
> -	Note that this also reverses any exclude list present.
> +	Show only ignored files in the output. When showing files in the
> +	index, print only those matched by an exclude pattern. When
> +	showing "other" files, show only those matched by an exclude
> +	pattern.

Hmmm... I do not see that much difference. But that might be justified
by my bad English.

> --- a/t/t3003-ls-files-exclude.sh
> +++ b/t/t3003-ls-files-exclude.sh
> @@ -29,4 +29,12 @@ test_expect_success 'add file to gitignore' '
>  '
>  check_all_output
>  
> +test_expect_success 'ls-files -i lists only tracked-but-ignored files' '
> +	echo content >other-file &&
> +	git add other-file &&
> +	echo file >expect &&
> +	git ls-files -i --exclude-standard >output &&
> +	test_cmp expect output
> +'
> +
>  test_done

Do that fit? shouldn't it be "test_cmp other-file output"? "git ls-files
- -i --exclude-standard" should show the files in the index that are also
in the exclude list. And you only add other-file to the index. And
shouldn't there be also a "echo other-file > .gitignore"?

Regards
   Klaus
- -- 
Klaus Ethgen                            http://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBSutGLJ+OKpjRpO3lAQqmZwgAi7DqPorAdp0dZtgMpgzCsrWTJx5xb/dv
voQ4K5pYmxG1PgLb8zY7ywIvcG36uakCGvwgFQxsLzSgg0hRO1UsQ8XFVqSPp62X
evsZ/On5LYHY3xz+Fl0cPM5oomtqY+ZmHAd5syj4oh6hSHM8J93RuQzGEfMshtrQ
NUfAbAVmjuA5d4Cl/SLNUvoLE6M6O3YGkCGKXA9aPQcker6W+nODExJgTqyh4RHK
ATfbPC6+VJGUPfjVGmrqHVW8LOb/wP7grEBMaHvGpP/ysh4FHjy6HtXLhyPSRES/
KpsMG5g0dF0dbS0qBgrIck+6cifiHNlAbxc5LF7tydFBMnRAmjDyeA==
=7JTn
-----END PGP SIGNATURE-----

Re: Bug#553296: gitignore broken completely

[Jeff King]

On Fri, Oct 30, 2009 at 09:01:48PM +0100, Klaus Ethgen wrote:

> > +test_expect_success 'ls-files -i lists only tracked-but-ignored files' '
> > +	echo content >other-file &&
> > +	git add other-file &&
> > +	echo file >expect &&
> > +	git ls-files -i --exclude-standard >output &&
> > +	test_cmp expect output
> > +'
> > +
> >  test_done
> 
> Do that fit? shouldn't it be "test_cmp other-file output"? "git ls-files
> -i --exclude-standard" should show the files in the index that are also
> in the exclude list. And you only add other-file to the index. And
> shouldn't there be also a "echo other-file > .gitignore"?

No, because it is building on the previous tests. The point of the test
is:

  - we already have 'file' tracked and in gitignore (from previous
    tests in the series)
  - we add other-file to have some other file which is tracked but not
    in gitignore
  - we check the output of "ls-files -i" to make sure that "file" is
    there, but "other-file" is not

-Peff

Re: Bug#553296: gitignore broken completely

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Junio,

Am Fr den 30. Okt 2009 um 20:51 schrieb Junio C Hamano:
> I am not sure; my head spins when I see "tracked but ignored" (you have
> a new one in the test) which is quite a bogus concept.
> 
> Does it mean "tracked but would be ignored if it weren't---perhaps it was
> added by mistake?"?

Right. Exact. Sorry if my arguing was a bit misunderstandable. (My
spellchecker do not know "misunderstandable", so I hope it is ok; I am
from Germany, we like long words. ;-)

Regards
   Klaus
- -- 
Klaus Ethgen                            http://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBSutG9J+OKpjRpO3lAQqBCQf+MWXaVdCeD7bT/dTCEQ8WfVKwISR6qNCP
wttV5oHnMp/f1mDWqhwYc4OUeOcLtkcV6pNf4oCMLY5v6zuvnLDgGB/8XW3l6JgZ
Y7m0UoSRu0s5Hux+VX/+CLwJ1cylstkwx3yOxcZ5VSXAgDlRIrt7LpwCsh/7lMSO
n5KUHw3/RodTwomxXUSRTQqU+SQMOUJrUvYR1EE9zR0YQkDKYqhulhUH+uirLaBQ
0rfJB7sTRqFfv2kHMLzO8t+jfco39cOZWTxlE1QBN1+k7aTZIJD2d79atfY7NLo0
2kCfcJXRurQ2rSpjUAbDVBo8JvkclnEnVLZP+s5kuwzej0hy4D2ocg==
=sN6Y
-----END PGP SIGNATURE-----

Re: Bug#553296: gitignore broken completely

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Fr den 30. Okt 2009 um 21:05 schrieb Jeff King:
> > > +	test_cmp expect output
[...]
> No, because it is building on the previous tests. The point of the test
> is:
> 
>   - we already have 'file' tracked and in gitignore (from previous
>     tests in the series)
>   - we add other-file to have some other file which is tracked but not
>     in gitignore
>   - we check the output of "ls-files -i" to make sure that "file" is
>     there, but "other-file" is not

Aha, now I get it, the "test_cmp" do check the _content_ of the file
expect and not the file expect itself.

Regards
   Klaus

Ps. Uh, oh, maybe I should truncate the Cc ;-) Ok, hoping that is ok so
too.
- -- 
Klaus Ethgen                            http://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBSutHuJ+OKpjRpO3lAQoL2gf8DixaPjnEkLhOZUK4VVsXU7zJ/bB3qWnP
71yq3sPA3Fi9Bq51d06YnxAQe/WqJWnOtSzgw8V5QquTaEM5Lqp6bgY49jynj6mf
wRSL+L4y+jpuerIQ/SK3yVcNw837URfQNDGFPNVSJAwGYfeMWiYh52fqwPVxO37p
wsNryc2CqpviaiqK12XwyEn7NHxPROdIRm0K8uezsw1fzWUcx4hN8IVbl8i8z0ss
brgyuMsT+R0GnazT/IndLkGniuBFBF2pdyD5uYv/lqF+q8TOC+iQzhxuA0cj/EC6
y5FuVCOTLA938bmclvhnl1hfzg4+6c5xoqqtWI2DzJoXkm2zJpvlLQ==
=VEYC
-----END PGP SIGNATURE-----

Re: Bug#553296: gitignore broken completely

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Fri, Oct 30, 2009 at 12:41:27PM -0700, Junio C Hamano wrote:
>
>> I've never understood the use of "ls-files -i" without -o, so in that
>> sense, I have done 2. myself already long time ago.
>> 
>> In other words, I do not really care that much, and the choice would be
>> between "0. do not do anything---the patch in question was a bugfix for
>> longstanding insanity" and your "4. -i without -o didn't make much sense
>> but now it does and here is the new meaning".
>
> OK, I think the patch I sent elsewhere in the thread should be applied,
> then, as it should make you, me, and Klaus happy.

Thanks; will queue on top of b5227d8.