Re: import files w/ history

From: Csaba Henk <csaba-ml@creo.hu>
Date: Mar 9, 2009, 05:15 UTC
Message-ID: <slrngr99ei.1t4t.csaba-ml@beastie.creo.hu>
In-Reply-To: <20090308001021.GA26167@coredump.intra.peff.net>

On 2009-03-08, Jeff King <peff@peff.net> wrote:

Show 14 quoted lines

> What you really want to do is say:
>
>   - for every commit, narrow the tree to _just_ the one file
>
>   - if there were no changes in the narrowed tree, just throw out the
>     commit
>
> You can use an --index-filter to do the former, and a --commit-filter to
> do the latter (or just use --prune-empty, which is a shorthand).
>
> Another poster had a similar problem, and you can see the right
> filter-branch recipe there:
>
>   http://article.gmane.org/gmane.comp.version-control.git/111991

Thanks, this did the job.

Show 12 quoted lines

>
> I think you need an extra '--' to separate the paths from the revisions
> in the rev-list arguments:
>
>   git filter-branch -- master -- sys/dev/disk/vn/vn.c
>
> but even that doesn't quite do what you want. It limits the commits that
> are shown, similar to your first attempt above, but it doesn't cut down
> the tree itself (OTOH, limiting by path rather than using --prune-empty
> is likely to run faster, since you won't even look at commits that are
> uninteresting. However, it may change the shape of your history with
> respect to branching and merging).

Finally I choose to add the path to the rev-list args -- 80 vs 15000 commits does make a difference. (I can still check if there was any histroy [I just coined this from "history" and "destroy" :)] and go back to the full-scan way if yes.)

But I still had a hard time with it... Finally I realized that if I do filtering this way, I have to start filtering from the topmost commit which affects the given file.

If I just start from origin/HEAD (assuming that it's on a commit which does not affect the file), then it won't be found as a key of the mapping created by git-filter-branch (as it's ignored because rev-listing was narrowed down to the file), and therefore filter-branch finally punts with "WARNING: Ref '<sha1>' is unchanged". I don't know if it's an intended behaviour, or something which could/should be improved, or at least documented... seems to be some sort of POLS violation to me (at least I was surprised :) ).

Regards, Csaba