Re: FFmpeg considering GIT

[Petr Baudis <pasky@suse.cz>]

On Thu, May 03, 2007 at 01:48:26AM CEST, Jakub Narebski wrote:
> About removing a commit: assume that you have the following history
> The problem exists _only_ if somebody based his/her work on commit
> C or its descendant, i.e. original D, E commits. He/she would have
> to rebase his/her work on top of _changed_ (moved) commits D' and E'.

"_Only_"?

I think it's just totally unsustainable to do this history rewriting in
an "upstream" git repository. You will get horridly confused, then
frustrated and then just move from software development to beekeeping.

Imagine what will happen in gitk --all - you will see many commits
several times in a row because each is part of different subhistory for
a given head. Merging between branches will become totally impossible.
People keeping their clones (or even forking history) will be confused
and horrified. Bits of patches inbetween the original commit and the
revert moment will lose their meaning, the history won't be trustworthy
anymore at all.

In the end, using these practices git will end up useful roughly as a
faster but crippled SVN. So please don't ever just suggests how random
git commands and features with special usage might work without
carefully explaining the implications and why this is _not_ the way to
use git. If ffmpeg insists on having an X feature and it's not feasible
to make it work well with principles git is built on, ffmpeg will be
better off without git and staying with SVN, if anything to not make git
bad name between frustrated ffmpeg users and developers.

PS: Beekeeping _is_ kind of cool, really.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett