Bug#553296: gitignore broken completely

-----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.

quoted

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.

quoted

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.

quoted

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 [off-list ref]
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-----