curious about the proper way to remove the effect of a single commit
from git history whose purpose was to add some content, but there's
more to it than that.
say, once upon a time, i added a sizable top-level directory (call
it /subdir) to a repo and committed that, then later learned i didn't
need it after all. if i use "git rm" to delete it, sure, it goes away,
but it's still there in the object store, taking up space.
the obvious solution is to use git filter-branch thusly:
$ git filter-branch --prune-empty --tree-filter 'rm -rf /subdir' HEAD
which should get rid of /subdir from all commits on the current
branch. so far, so good.
but what if i added /subdir once upon a time, removed it with "git
rm", then later added it back with that same name (/subdir) but
totally different content -- effectively, having no relationship with
the earlier content of /subdir. if that's the case, the above command
would wipe out both versions, correct?
it seems(?) that if i want to truly prune just that earlier version
of /subdir, i can use a simple variation of the "--commit-filter"
option. for example, the man page shows this example to remove all
commits by a particular committer:
$ git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
then
skip_commit "$@";
else
git commit-tree "$@";
fi' HEAD
if that's the case, then it seems all i would need to do is identify
the commit that added that earlier content, and run:
$ git filter-branch --commit-filter 'skip_commit <commitID>' HEAD
as long as that earlier version of /subdir was added by that single
commit, would this do what it appears to do? or am i making this too
difficult?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================