James Sadler schrieb:
> 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@xxxxxxxx>:
>> On Fri, May 09, 2008 at 11:01:47AM +1000, James Sadler wrote:
>>> 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.
It's expected to do B.
> 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.
At this point you don't need subdirectory-filter. Use an --index-filter to
keep only the subdirectory *and* remove the directory name at the same
time. Something like this:
git filter-branch --index-filter \
'git ls-files -s thedir | sed "s-\tthedir/--" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
> 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.
The bit-for-bit correctness is not surprising, but the incorrect history
is. What is your definition of "correct" (i.e. can you give an example of
your expectations that are not met)? Do you have complicated history (with
merges)? Note that merges are removed if all but one of the merged
branches do not touch the subdirectory.
-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
