Re: import files w/ history

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

 



On 2009-03-08, Jeff King <peff@xxxxxxxx> wrote:
> 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.

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

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