On Tue, May 17, 2011 at 9:07 PM, Gerald Storer <g...@mrxtech.com.au> wrote:
> 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.
>
>
Don't know if this was a mistake or not, but I see that commit e7f1e83 (the
one to fix a clipping issue when a patch's line width is 1 but there is no
color) seems to have been merged back into itself... somehow... in commit
0c886b8. I have seen things like this before, and I never quite understood
how they happen. Plus, do we want to get that patch merged down to master?
I think we definitely need to see what sort of controls we can put in place
to prevent mix-ups in the future. One thing I did like about SVN was that
it was next to impossible to change the history. Meanwhile, with git, it
becomes possible. Is there some way we can disallow forced pushes, maybe?
Just a thought...
Ben Root
------------------------------------------------------------------------------
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
