The actual problem has multiple files, at different locations in the file 
hierarchy.
Copying and restoring them then becomes a minor pain.  Probably I could use
a clever tar command, or something similar.  It would be a whole lot easier 
if
git rm --cached used in an --index-filter command worked the same way as
git rm --cached works when used standalone.  

On Monday, August 19, 2013 10:48:59 AM UTC-7, John McKown wrote:
>
> If it is still in the working directory, why not rename it (using OS 
> commands, not git command), do the git command to remove all traces as 
> previously mentioned, then rename it back? 
>
>
> On Mon, Aug 19, 2013 at 12:38 PM, Dale R. Worley 
> <wor...@alum.mit.edu<javascript:>
> > wrote:
>
>> > From: joeri...@gmail.com <javascript:>
>> >
>> > At some point I added a large file into a git repository.
>> > It now exists on multiple branches, possibly with some
>> > changes to it.  I'd like to remove it from git, but leave its
>> > current form (say the one on the master branch) on the
>> > file system.
>>
>> You've figured out how to remove it from the repository.  To keep a
>> copy around, I would extract it explicitly with "git cat-file" and put
>> it somewhere outside of the working copy before doing "git
>> filter-branch".
>>
>> Dale
>>
>> --
>> 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+...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> As of next week, passwords will be entered in Morse code.
>
> Maranatha! <><
> John McKown
>  

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