-----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@xxxxxxxxx>
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-----
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html