On Tue, 18 Dec 2012 07:47:22 -0800 (PST)
John McKown <john.archie.mck...@gmail.com> wrote:
> What about something like the following (on Linux)
> git checkout -b newbranch
> git ls-files | fgrep -v 'file.to.keep' | while read i;do git rm
> # newbranch now only contains "file.to.keep"
1) Only provided you then `git add -u` and `git commit` the changes.
2) Only this new commit made in the previous step will only contain
"file.to.keep" -- every commit down the line of history will still
contain all the other files. Not only this makes the file's history
"impure" but merging such a tree to another branch will bring all
this history with the merge commit.
> git checkout B
> git merge newbranch
> git -d newbranch
> I'm not too sure about this. I'm still too new at git to be sure of
> the "git ls-files" doing what I think.
To do such mass removals of unwanted stuff from *whole* lines of
history, the `git filter-branch` tool was written. So yes, by applying
`git filter-branch` to a copy of the branch from which we want to
extract the history of a single file, it's possible to achieve what you
intended. The problem which remains with this approach is tracking
file renames: Git does not track file renames explicitly (like, say,
Subversion does) and each call to the script you pass to
`git filter-branch` will see the state of the branch pulled out of
context. I'm not sure there's a usable way to somehow find out on
each such step if a file has been renamed or not.