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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 9, 2007, 02:40 UTC
Message-ID: <alpine.LFD.0.98.0706081822500.4205@woody.linux-foundation.org>
In-Reply-To: <200706082328.50923.johannes.sixt@telecom.at>

On Fri, 8 Jun 2007, Johannes Sixt wrote:

Show 5 quoted lines

>
> 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