From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 31 Mar 2008 08:40:09 GMT
Subject: Re: [PATCH] filter-branch: Fix renaming a directory in the tree-filter
Message-ID: <7v3aq7mgly.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1206947655-20272-2-git-send-email-johannes.sixt@telecom.at>

Johannes Sixt <johannes.sixt@telecom.at> 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