Re: Understanding git filter-branch --subdirectory-filter behaviour

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 21, 2008 at 7:26 AM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxx
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
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux