On Fri, Sep 15, 2017 at 07:06:43AM -0400, Robert P. J. Day wrote:
> > I think you want to stick with a --tree-filter (or an
> > --index-filter), but just selectively decide when to do the
> > deletion. For example, if you can tell the difference between the
> > two states based on the presence of some file, then perhaps:
> >
> > git filter-branch --prune-empty --index-filter '
> > if git rev-parse --verify :dir/sentinel >/dev/null 2>&1
> > then
> > git rm --cached -rf dir
> > fi
> > ' HEAD
> >
> > The "--prune-empty" is optional, but will drop commits that become
> > empty because they _only_ touched that directory.
> >
> > We use ":dir/sentinel" to see if the entry is in the index, because
> > the index filter won't have the tree checked out. Likewise, we need
> > to use "rm --cached" to just touch the index.
>
> got it. one last query -- i note that there is no "else" clause in
> that code for "--index-filter". am i assuming correctly that if i was
> using "--tree-filter" instead, i really would need if/then/else along
> the lines of:
>
> if blah ; then
> skip_commit "$@"
> else
> git commit-tree "$@"
> fi
>
> thank you kindly.
No, I think a tree-filter would just be:
if test -e dir/sentinel
then
rm -rf dir
git add -u
fi
(I can't remember if the "add -u" is necessary or not; I rarely use tree
filters).
In other words, for each commit you are just saying "if the bad version
of the directory is present, then get rid of it". You shouldn't need to
deal with commit-tree at all. The filter-branch script will take care of
committing whatever tree state your filter leaves in place.
Do note that I didn't test either of the versions I sent to you, so it's
possible I'm missing some subtle thing. But I'm pretty sure the general
direction is correct.
-Peff
