Johannes Sixt <johannes.sixt@xxxxxxxxxx> writes: > 2. Then filter-branch checks out the files for the next commit. This > leaves the new directory behind because there is no real "branch > switching" involved that would notice that the directory can be > removed. Thanks. It obviously is a correct fix to use "clean -d" here, but I strongly suspect this awkwardness comes from the fact that there is no clear invariant in this loop. For example, if you make it the invariant that $T contains the tree that matches the contents of the "$tempdir/t" work tree left in the previous round of filter-tree (and obviously you would want to do this only filter_tree is in effect), the "checkout-index + clean" would become a proper "branch switching". This is obviously untested, and you would need to prime $T with an empty tree before entering the loop (but you could cheat by initializing T with an empty string), but it might make the code a bit more readable than the current mess. I dunno. if [ "$filter_tree" ]; then - git checkout-index -f -u -a || - die "Could not checkout the index" - # files that $commit removed are now still in the working tree; - # remove them, else they would be added again - git clean -d -q -f -x + git read-tree -m -u $T $commit eval "$filter_tree" < /dev/null || die "tree filter failed: $filter_tree" - ( - git diff-index -r --name-only $commit - git ls-files --others - ) | - git update-index --add --replace --remove --stdin + git add -u && git add . && T=$(git write-tree) fi -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
