I think I have stumbled on a bug in the -d option of git filter-branch.
It seems like in the final stage of filter-branch, regardless of where
-d is set, it will make updates to the "working directory" as being the
parent of the -d directory, and the actual working directory is left as
it were before the filtering.
For example if using -d /tmp/git-rewrite, the new checkout files are
dumped into /tmp.
A simple test scenario:
echo foo >foo
git add foo
git commit -m"foo"
echo bar >bar
git add bar
git commit -m"bar"
git checkout -b rewrite
git filter-branch -d /tmp/git-rewrite --tree-filter 'echo baz >baz' --
# git status
# shows 'baz' as unstaged-deleted in the working directory
# ls /tmp/
# shows the 'baz' file created in the root, above git-rewrite
# git log --stat --oneline
# does show expected result though
# if you run it again you'll get an error because of the /tmp/baz file
git reset --hard master
git filter-branch -f -d /tmp/git-rewrite --tree-filter 'echo baz >baz'
# Rewrite afac18542ac3d432b647866f5ac6918b81b3bb78 (2/2)
# Ref 'refs/heads/rewrite' was rewritten
# error: Untracked working tree file 'baz' would be overwritten by
# At this point, 'baz' is instead staged-deleted in the working
Martin Erik Werner <martinerikwer...@gmail.com>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html