[PATCH 2/2] filter-branch: subdirectory filter needs --full-history

When two branches are merged that modify a subdirectory (possibly in
different intermediate steps) such that both end up identical, then
rev-list chooses only one branch. But when we filter history, we want to
keep both branches. Therefore, we must use --full-history.

Signed-off-by: Johannes Sixt <redacted>
---
 git-filter-branch.sh     |    2 +-
 t/t7003-filter-branch.sh |   21 +++++++++++++++++++++
 2 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 4ef4570..2e4ccec 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh

@@ -326,7 +326,7 @@ case "$filter_subdir" in
 	;;
 *)
 	git-rev-list --reverse --topo-order --default HEAD \
-		--parents "$@" -- "$filter_subdir"
+		--parents --full-history "$@" -- "$filter_subdir"
 esac > ../revs
 commits=$(cat ../revs | wc -l | tr -d " ")
 

diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 292b837..0fabe49 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh

@@ -78,4 +78,25 @@ test_expect_success 'subdirectory filter result looks 

okay' '
 	! git show sub:subdir
 '
 
+test_expect_success 'setup and filter history that requires --full-history' '
+	git checkout master &&
+	mkdir subdir &&
+	echo A > subdir/new &&
+	git add subdir/new &&
+	test_tick &&
+	git commit -m "subdir on master" subdir/new &&
+	git rm a &&
+	test_tick &&
+	git commit -m "again subdir on master" &&
+	git merge branch &&
+	git-filter-branch --subdirectory-filter subdir sub-master
+'
+
+test_expect_success 'subdirectory filter result looks okay' '
+	test 3 = $(git-rev-list -1 --parents sub-master | wc -w) &&
+	git show sub-master^:new &&
+	git show sub-master^2:new &&
+	! git show sub:subdir
+'
+
 test_done
-- 
1.5.2

On Fri, 8 Jun 2007, Johannes Sixt wrote:

When two branches are merged that modify a subdirectory (possibly in
different intermediate steps) such that both end up identical, then
rev-list chooses only one branch. But when we filter history, we want to
keep both branches. Therefore, we must use --full-history.

--full-history needs to be fixed up for this, I think.

It leaves *too* many merges around, in particular, it leaves merges where 
both parents end up (after simplification) being related to each other.

As an example, do this:

	mkdir hello
	cd hello/
	git init

	echo "Initial state" > file-A
	echo "Another initial state" > file-B
	git add file-A file-B
	git commit -m "Initial commit"

	echo "Add a line" >> file-A
	echo "Add another line" >> file-B
	git commit -a -m "On master branch"

	git checkout -b another HEAD^
	echo "Add a line" >> file-A
	git commit -a -m "On another branch"

	git checkout master
	git merge another

and then do

	gitk --full-history file-B

and notice what happens.. There was no actual developmet on branch 
"another", so all the commits went away, but it left the merge (because 
that's how --full-history works), which has now become pointless.

So you should do a "merge cleanup" phase after running --full-history.

			Linus