Re: Understanding git filter-branch --subdirectory-filter behaviour
- From
- David Tweed <david.tweed@gmail.com>
- Date
- May 22, 2008, 18:05 UTC
- Message-ID
- <e1dab3980805221105k15908606s3397ba1a96ecf081@mail.gmail.com>
- In-Reply-To
- <4833C07B.3060004@viscovery.net>
On Wed, May 21, 2008 at 7:26 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
Show 7 quoted lines
> David Tweed schrieb: > That's difficult to tell without a peek at the repository. > > Did you compare 'gitk HEAD' to 'gitk HEAD -- WRITING'? I'd expect the > latter to be a subset of the former. Note that with a path specified > "history simplification" happens, which means that you won't see as many > merges as when no path is specified.
Just did that in the before-filtering repository, and "gitk HEAD -- WRITING" doesn't have any branches after the simplification but it does go back to the first commit in the repository creating WRITING (presumably simplifying out several branches that didn't affect WRITING), whereas the filtered repository starts on the commit immediately after the first merge you encounter walking backwards in time. I was prepared for the branch structure to possibly simplify whilst keeping all the commits that change that directory, but was a bit surprised it stopped before the first merge.
<in original> $ git log HEAD -- WRITING | wc -l 2033
<in filtered repo> $ git log | wc -l 329
So it's definitely creating a smaller repo than git log filtering. If you would be interested in looking at the actual repo (about 17M) let me know and I'll send you tarball details via personal mail.
Anyway, many thanks for the insight and assistance,
-- cheers, dave tweed__________________________ david.tweed@gmail.com Rm 124, School of Systems Engineering, University of Reading. "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot