From: Andy Parkins Date: Fri, 04 May 2007 15:53:47 GMT Subject: Re: FFmpeg considering GIT Message-ID: <200705041653.49486.andyparkins@gmail.com> In-Reply-To: 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@gmail.com