On Mon, 19 Aug 2013 11:06:09 -0700 (PDT)
joeriel...@gmail.com wrote:

> > > 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. 
> > > 
> > > I tried (on a dummy git archive) 
> > > 
> > > git filter-branch --index-filter 'git rm --cached
> > > --ignore-unmatch bigfile' master branch1 branch2 
> > > 
> > > That, however, does not leave a copy of bigfile on the file
> > > system. It isn't clear to me why not, though the description of
> > > the 
> > > --tree-filter option to filter-branch (I'm using the
> > > --index-filter option, but is is "similar") states: 
> > > " (new files are auto-added, disappeared files are 
> > > auto-removed ... )".   
> > If you wonder why the file disappears from the work tree during the 
> > filtering process, my take on it is that 1) the work tree is used
> > as a scratch space during the filtering, and 2) the work tree
> > (normally) contains the same state HEAD does, so if filtering
> > deleted the file from HEAD it's logical the work tree does not
> > contain it as well. 
> >
> I wonder because
> git rm --cached bigfile 
> does *not* remove the file from the working directory.  It's not
> clear, then,
> why the file is removed in the filter-branch call. What is the point
> of passing --cached to the call to git rm in the --index-filter
> command? Is it merely for efficiency?  It seems to have the same
> effect without it. That is not the case when using git rm alone:
> git rm bigfile 
> removes the file from working directory as well as the index.

That is an interesting insight, indeed, and I missed it when I read
your message.  My take on this is that the behaviour you're observing
is not really intentional (as it's not documented) -- supposedly the
tool just brings the work the to the state of the HEAD if the HEAD
points to a ref which has been updated.

Your problem feels like a corner-case to me but why not -- I would
definitely bring this problem on the main Git list [1].  The tool's
documentation hints that it does much I/O using the $TEMP directory
which suggests it might not really touch the work tree if it only
operates on the index, so may be you'll be lucky and the tool could be
fixed to not really touch the work tree if --index-filter is used.

1. https://gist.github.com/tfnico/4441562

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