git rm --cached takes multiple files, so I don't see the problem with that. 
 Say if you saved all the filenames in a file, you can do

cat rm-these-files | xargs git rm --cached



On Friday, August 23, 2013 2:47:43 PM UTC-7, Dave Williams wrote:
>
> I am dealing with a large project where people have committed files before 
> setting up .gitignore properly or have subsequently committed with "git add 
> -f"
> 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 
>
> http://stackoverflow.com/questions/9320218/how-to-list-gitignore-files-that-are-currently-staged-or-committed
> 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)?
>
> Dave
>
>
>
>
>

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