On 18/05/2011 5:14 AM, Eric Firing wrote: > 3) We don't have to always push sets of changes from an original pull > request to upstream; they can be consolidated using any of a variety of > methods to form a new local feature branch with the same net effect but > fewer commits (maybe only one), and then that can be merged (which > should be fast-forward, no merge commit) and pushed to upstream. This > takes a little more work than simply accepting (merging) a pull request > as-is, but in many cases it may be worth it because it can yield a > cleaner history. Similarly, if someone is developing a feature branch > on github, and the net effect is correct but the branch has intermediate > commits that distract from the net result, then a good practice would be > for that person to consolidate the changes into a new feature branch > with a cleaner history, close the pull request on the old one and open a > new request for the polished branch. > I believe this script more or less automates the process: https://github.com/jeresig/pulley
Gerald. ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
