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 - 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