Re: My use case

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