I am dealing with a large project where people have committed files before 
setting up .gitignore properly or have subsequently committed with "git add 
As a result there are lots of files that should not be under version 
control that need removing but equally there are some exceptions that 
should be tracked.

I can list the "tracked but would have been ignored" files using the alias 
described in 
which works reasonably well.  I can then look at the files and then 
determine their fate.

For the exceptions files I want to add a negation .gitignore rule to make 
it clear that tracking them was intended rather than just living with the 
fact they are already being tracked. It also means I can ultimately clear 
the index and re-import all the files with a "git add ." to deal with the 
large number of files that shouldn't be there in one action.

Check-ignore would help me deveIop/check the new rules but it checks the 
index first and matches anything already being tracked. It does this in 
order to be consistent with git status and git add characteristics. This 
means the files I am looking at never show up.

I dont particularly want to remove the entries (git rm --cached) file by 
file (or delete the whole index until I am ready)  so that check-ignore 
can tell me which rule is being applied. Is there another way of achieving 
the same thing?

If not this does seem like a reasonable use case in terms of debugging 
-i.e. to report the rule status irrespective of whether the test path name 
is already being tracked. Therefore might there be an argument for adding 
another program option to do this (its trivial to implement)?


You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to