Bug#553296: gitignore broken completely

[Klaus Ethgen <Klaus@Ethgen.de>]

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