Re: My use case

> Excerpts from Ron Garret's message of Sat Jan 30 03:26:19 -0500 2010:
> > 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.)
> 
> My approach, in this case, would be to use git log, possibly git log -p,
> in order to view the changes in each file you were interested in rolling
> back.  If the rollback falls on a commit boundary, great; you can use
> `git checkout rev -- path`.  If not, you can perform that, and then
> use git checkout -p to selectively revert hunks in the patch (fundamentally,
> you can't really get better than that).

> > 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.
> 
> While Git's ability to look at individual file's history is "slower", it's 
> still
> quite excellent, and you are encouraged to use it as necessary.