Re: git filter-branch --subdirectory-filter

From: Jeff King <peff@peff.net>
Date: May 9, 2008, 01:33 UTC
Message-ID: <20080509013300.GA7836@sigill.intra.peff.net>
In-Reply-To: <e5e204700805081801x314b02bek5d53a086b02dac83@mail.gmail.com>

On Fri, May 09, 2008 at 11:01:47AM +1000, James Sadler wrote:

> I have a git repository that I wish to split into multiple seperate
> repositories for each logical module that it contains. Each logical
> module is already in its own directory at the root of the repo.

OK.

> To extract a module into its own repo, I first copied the original
> repo (this was a simple cp -r, as it seemed to be the simplest way as
> git clone doesn't get all the branches)

It does copy them, but they're just "remote tracking branches". If you have many branches, you can recreate them via a loop with git-branch, or by "git fetch . refs/remotes/origin/*:refs/heads/*". If you have only one branch, you might just want to make a few copies of it with "for i in repo1 repo2; do git branch $i master; done", and then filter-branch those branches.

In either case, your cp is fine, if just a little less efficient.

> and ran filter-branch with a --commit-filter to skip commits that were
> irrelevant to th subdir.

But that's part of what subdirectory-filter does, so this step is unnecessary.

> The next pass was to 'hoist' the contents of the subdir in the new
> repo into the root dir.

And that's the other part of what subdirectory-filter does.

> I thought I could do this with a --subdirectory-filter argument to
> filter-branch, except when I do this, I loose tons of commits.  (The
> working tree is correct, i.e. the same as the original repo working
> tree, but the history is screwed).

You'll have to be more specific about what's wrong with history. Of course some commits will be gone after filtering the subdir (those that didn't touch anything in the subdir); that's part of the point.

-Peff