Easy way to verify gitignore files?

On Wed, Sep 22, 2010 at 8:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

It's not hard to tell if we're missing a file that ought to be listed
in .gitignore --- git status will find that problem soon enough.
However, it seems that git isn't so willing to tell you about gitignore
patterns that cover too much, i.e. match files that are already in the
repository.  I found out by accident that you will only hear about this
when you try to "git add" such a file after changing it.  This seems
pretty dangerous, especially for people who are willing to rely on
"git commit -a" :-(

Is there any automated sanity check that we can run to find this sort
of problem?  I suspect that we probably have got some errors in the
.gitignore files, particularly in the back branches, and it would be
nice to find them now before they get in the way of normal development.

I assume one could write a perl script to check this pretty simply...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas@gmail.com> writes:

On Wed, Sep 22, 2010 at 8:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Is there any automated sanity check that we can run to find this sort
of problem? �I suspect that we probably have got some errors in the
.gitignore files, particularly in the back branches, and it would be
nice to find them now before they get in the way of normal development.

I assume one could write a perl script to check this pretty simply...

No doubt, but I was hoping somebody already had. In particular, it'd
be best if one could use git's own logic for matching .gitignores,
rather than reimplementing it in a way that might or might not behave
quite the same.

regards, tom lane

At 2010-09-22 20:54:19 -0400, tgl@sss.pgh.pa.us wrote:

However, it seems that git isn't so willing to tell you about gitignore
patterns that cover too much, i.e. match files that are already in the
repository.

If .gitignore specifies a pattern that matches something that's already
in the repository, that specification is itself ignored, and the file is
treated like any other file.

This seems pretty dangerous, especially for people who are willing to
rely on "git commit -a" :-(

There is no danger. "git commit -a" will commit changes to files that
match .gitignore but are already in the repository. (I vaguely remember
that there were bugs in this regard in old versions of git, but it's not
a problem with any recent version AFAIK.)

-- ams

On 23 September 2010 11:28, Abhijit Menon-Sen <ams@toroid.org> wrote:

This seems pretty dangerous, especially for people who are willing to
rely on "git commit -a" :-(

There is no danger. "git commit -a" will commit changes to files that
match .gitignore but are already in the repository. (I vaguely remember
that there were bugs in this regard in old versions of git, but it's not
a problem with any recent version AFAIK.)

Right; .gitignore patterns are only applied to untracked files. Once
a file is tracked by git, you can try to gitignore it all you like, it
won't have any effect.

Cheers,
BJ

Abhijit Menon-Sen <ams@toroid.org> writes:

At 2010-09-22 20:54:19 -0400, tgl@sss.pgh.pa.us wrote:

However, it seems that git isn't so willing to tell you about gitignore
patterns that cover too much, i.e. match files that are already in the
repository.

If .gitignore specifies a pattern that matches something that's already
in the repository, that specification is itself ignored, and the file is
treated like any other file.

I can demonstrate that this is not so. Try a "git add" on such a file.
It fails --- at least it does with the version of git currently in
Fedora 13. You get some nasty warning about how there's a conflicting
.gitignore pattern and you have to use -f if you want to add.

regards, tom lane

At 2010-09-22 22:19:45 -0400, tgl@sss.pgh.pa.us wrote:

I can demonstrate that this is not so. Try a "git add" on such a file.

Works fine for me with v1.7.3 (no warnings, no need for add -f). What
version do you use?

If I try to add an untracked file which is already ignored, then I get
the warning.

-- ams

$ git init a; cd a
Initialized empty Git repository in /home/ams/a/.git/
$ echo foo > a; git add a; git commit -m 1
[master (root-commit) 0031fcb] 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
$ echo a > .gitignore; git add .gitignore; git commit -m 2
[master ed019e5] 2
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
$ echo bar > a; git add a; git commit -m 3
[master 19e5d2a] 3
1 files changed, 1 insertions(+), 1 deletions(-)
$ echo baz > a; git commit -a -m 4
[master 73da20a] 4
1 files changed, 1 insertions(+), 1 deletions(-)

Hi,

On Thursday 23 September 2010 02:54:19 Tom Lane wrote:

Is there any automated sanity check that we can run to find this sort
of problem? I suspect that we probably have got some errors in the
.gitignore files, particularly in the back branches, and it would be
nice to find them now before they get in the way of normal development.

git clean -nx shows you all ignored files that are not checked if thats what
you want...

Andres

Tom Lane <tgl@sss.pgh.pa.us> writes:

However, it seems that git isn't so willing to tell you about gitignore
patterns that cover too much, i.e. match files that are already in the
repository.

It seems to me that git-ls-files is what you want here :
http://www.kernel.org/pub/software/scm/git/docs/git-ls-files.html
git ls-files -i --exclude-standard

Regards,
--
dim

Dimitri Fontaine <dfontaine@hi-media.com> writes:

Tom Lane <tgl@sss.pgh.pa.us> writes:

However, it seems that git isn't so willing to tell you about gitignore
patterns that cover too much, i.e. match files that are already in the
repository.

It seems to me that git-ls-files is what you want here:
git ls-files -i --exclude-standard

Ah-hah, that does what I want, and indeed it shows that we've got some
issues. Working on cleaning them up. Thanks!

regards, tom lane