Checkout a single file so that history is retained

Question

My aim is to create a new github repo, containing some files from a repo that I have forked (and then effectively forked within my own github, using http://deanmalone.net/post/how-to-fork-your-own-repo-on-github/

I've found that in my repo, if I move files around so that they end up like I want them, the git history is removed (well, normally, and even when it isn't, github doesn't show the history until you go back to the parent commit - so all the people who actually did the work aren't listed as contributors - which I'd really like to avoid).

So, I tried doing a sparse checkout

git init
<set remote>
git fetch
git checkout origin/master -- python/file.py

but this creates python/file.py, rather than file.py, which is what I need. I obviously can't mv the file, because that has the same problem I found at the beginning.

I see two options, but haven't found how to achieve either

• is there a way to save python/demo.py into the current directory using git checkout or some other way I haven't found? (git archive won't work)
• can I set a new remote URL from a subdirectory? i.e. cd into python and then set the remote so that only file.py is committed into my repo?

Answer 1

In Git, history is commits; commits are history. There is no such thing as "file history".

It's true that git log -- somefile.py shows you the history that affects somefile.py. But the way it does that is to look at all the commits, starting from the current one, working backwards one commit at a time. At each commit, it diffs the parent commit against that commit. Did somefile.py change between parent and child? If so, print the commit. If not, print nothing. In either case, continue on to the parent commit.

(Things get a little tricky at merge commits, which by definition have more than one parent. Here Git defaults to following whichever parent didn't change somefile.py.)

If you add --follow to your git log, Git does one extra thing: when it compares parent and child, it checks to see if the diff from parent to child says that the file was renamed. If so, as soon as it moves to the parent, it starts looking for the old name of the file. But you're still looking at some subset of commit history, in all cases. If you have the commits, Git will look at them, and print some of them. If you don't have the commits, you don't have any history.