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