On Friday 2007 May 04, Michael Niedermayer wrote: > well, my example above was exagerated, noone ever reindented the whole > ffmpeg or checked in a old version over HEAD. what did and does > occasionally happen is that people check in several things at once (like a > 100k reindenton mixed with various functional changes) > for these we currently copy the last good version of the affected files > over the current one with svn cp and then apply the changes in nicely > split manner. (possibly without the reindention if its uneeded ...) I might be misunderstanding, but doesn't that leave the "bad" commit in the history? * -- * -- G -- B -- !B -- 1 -- 2 -- 3 B is the bad commit; !B would be the result of the svn cp from the previous known-good revision, "G"; then 1, 2, and 3 would be the correctly split version of "B". Have I correctly understood? If so - git would have no trouble at all emulating that. !B would actually be easier to create because you could use git-revert to automatically create the inverse of B. If you wanted to only revert a single file, well you could use git-checkout G-REVISION -- file To pull only that file out of G, and then commit that back, before starting the tidy up. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@xxxxxxxxx - 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