Re: git filter-branch --subdirectory-filter

From: James Sadler <freshtonic@gmail.com>
Date: May 9, 2008, 07:38 UTC
Message-ID: <e5e204700805090038k373bbabcyfb10d8c93ec5b3a7@mail.gmail.com>
In-Reply-To: <20080509013300.GA7836@sigill.intra.peff.net>

Hi Jeff,

After reading your reponse and re-reading my original email, I realised it was totally unclear so I have re-explained myself below.

2008/5/9 Jeff King <peff@peff.net>:

Show 11 quoted lines

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

I must have experienced a brain fart or something or missed the '-r' from git branch...

Show 5 quoted lines

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

Yes that's true, but...

Clearer explanation:

I originally tried --subdirectory-filter by itself to see if it would do the job, but it filtered more commits than I thought it should (some commits that touched the subdir were missing after filter-branch was run).

I then began to question my understanding of the semantics of subdirectory-filter.

Is it meant to: A) Only keep commits where ALL of the changes in the commit only touch content under $DIR? B) Only keep commits where SOME of the changes in the commit touch content under $DIR?

I suspected that it was behaving as A.

That's when I decided to run the commit-filter first in combination with the tree-filter. This would leave me with all commits that touched the subdir but any commit that touched multiple subdirs would be cleaned up so it only touched the subdir I want to keep.

At this point I have a bunch of commits that only make changes to subdir (verified using gitk), and I would expect subdirectory-filter to keep every single commit.

However, after running it, I loose most of my commits. Strangely, the working tree is bit-for-bit correct with the original version or the subdir in the old repo, but the history leading up to it is not.

--subdirectory-filter does not seem to behave as either A or B above but something other way. I'm sure it will turn out to be something silly, but I'm pulling my hair out trying to figure this one out.

Hopefully that's a clearer explanation!

-- 
James