Re: FFmpeg considering GIT

From: Andy Parkins <andyparkins@gmail.com>
Date: May 4, 2007, 15:53 UTC
Message-ID: <200705041653.49486.andyparkins@gmail.com>
In-Reply-To: <loom.20070504T143538-533@post.gmane.org>

On Friday 2007 May 04, Michael Niedermayer wrote:

Show 7 quoted lines

> 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