My use case

My recent question about checking out an upstream commit (and ending up as a result on a detached head) has generated a lot of discussion and useful information. I thought I'd describe what I'm actually up to because someone might have some ideas on how to do it better.

I'm trying to integrate git into a Lisp IDE (Clozure Common Lisp). Because it's Lisp, code is often developed incrementally and experimentally. This has two important consequences. First, the files in your working directory can and often do, as part of the normal course of events, get into an incoherent state. Everything in your running Lisp image is working just fine, but if you try to recompile your entire system something will break, and you can go for a very long time without discovering that this has happened. Second, development can often lead to dead-ends where you want to throw everything you've just done away, go back to some earlier version of *some but not all* of your code, and start over.

In other words, it is not uncommon to want to roll back an individual file or set of files to an earlier version and leave the rest of the tree alone. git can do this, but it's not straightforward. Simply rolling back through the history of the current branch doesn't work because you might want to roll back file A, but the last dozen revisions or so have been changes to file B. You might also want to roll both A and B back to states which never co-existed in the original history.

One approach is to use git rev-list to find those commits where particular files changed, but this is sub-optimal for several reasons. First, a naive approach calls rev-list for every rollback, and rev-list has to traverse the entire history, so it's very inefficient. Second, if you roll back a single file, git doesn't keep track of that file's provenance, so you have to manually track which files and have been rolled back and which revisions they have been rolled back to. (There was a third problem but I can't think what it was right now.)

I have this intuition that git can be made to really do this right by keeping a separate history of every individual file in addition to a history of the entire source tree. Git can't do this directly as far as I know. I'd be writing additional code to generate extra tree and commit objects every time a file was saved from the IDE. But turning this intuition into reality is turning out to be quite challenging. So I'm going with the rev-list approach for the first version despite its shortcomings.

If anyone has ideas or suggestions, feedback would be much appreciated. But this is mostly just FYI.

rg