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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 13, 2007, 06:58 UTC
Message-ID: <7vps40fihe.fsf@assigned-by-dhcp.pobox.com>
In-Reply-To: <alpine.LFD.0.98.0706081822500.4205@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 5 quoted lines

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

In short, you will end up with something like this:

             .---. (side branch)
            /     \
	---A---B---C (merge)

The "merge clean-up" would conceptually be a simple operation. Whenever you see a merge C, you look at its parents A and B, and cull the ones that are reachable from other parents. You notice that A is an ancestor of B, drop A from the parents of C, and simplify the above down to:

	---A---B---C (not-a-merge)

However, I suspect that this is impossible without making --full-history with "merge clean-up" imply "limited".

In the case of filter-branch, it needs to use topo-order in order to guarantee that all its parents commits have been rewritten before rewriting a commit, so the traversal is already limited.

It might be simpler for filter-branch to remove parents that are ancestor of other parents ("git show-branch --independent" would work well for this, I think), before feeding the list of mapped parents to the parent-filter.