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. Slightly relatedly, I'd recommend flushing to disk and committing more often. It's great that the LISP REPL allows for more daring changes, but having a history either way is very helpful! Cheers, Edward -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html