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
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
For more options, visit https://groups.google.com/groups/opt_out.