On Fri, Feb 4, 2011 at 2:48 PM, Jesus Cea <j...@jcea.es> wrote: .. > I am not sure what way is better. Keeping ALL the history would be > interesting anyway, but most of my tiny commits would break the build (I > commit everytime I stop for thinking, pee, whatever. It is like autosave > in my text editor), so things like "bisect" would be difficult to use. > And reviewing 200 stupid patches when patch n+20 undo buggy patch n+1, > is not pleasant. > > This is a social issue.
Let's take the use case of Python development since it's what we discuss here. You are building a patch and submit it to reviews (in roundup or in a clone or retvield etc). You get feedback and you refine the patch. I don't think you want to keep that history, e.g. "changing this and that in my patch after feedback from MrX about Y" The main line history is what counts imo, not the history of how your patch was built, refactored etc. before it got merged. >> I don't want to fork this thread but I think we should set up a >> "mercurial good practice" guide somewhere for hg.python.org could be >> awesome, in particular since the number of indirect contributors is >> going to grow with Python under a DVCS > > +1. But first we need the mercurial switchover to be done and to get > some first hand experience before writing down the best practices *wiki* :). I'd rather have a best practice guide *now* and refine it later. e.g. "how to contribute to python via mercurial." I think we have people here with a decent expertise of Mercurial that can come up w/ this, even if it's changed after. Cheers Tarek -- Tarek Ziadé | http://ziade.org _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
