On Wed, May 18, 2011 at 3:22 PM, Eric Firing <efir...@hawaii.edu> wrote: > On 05/18/2011 08:47 AM, Benjamin Root wrote: >> >> >> On Tue, May 17, 2011 at 9:07 PM, Gerald Storer <g...@mrxtech.com.au >> <mailto: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? > > Yes, it needs to get merged to master; but no, I don't think anything > was "merged back into itself"; instead, it is just a case where a > fast-forward with no merge commit would have left a simpler history--one > commit instead of two. > > Merging from v1.0.x to master doesn't have to be done after every change > to v1.0.x, but it shouldn't be left undone for very long. A few days > ago I wasted a chunk of time thrashing around on master because of a bug > that had been fixed on 1.0.x but was not yet merged into master--and I > had not thought to check their relative states. The bug had actually > been introduced to master via a recent change merged from 1.0.x. > > We are experiencing some bumps on the git/github learning curve, but not > nearly enough to make me pine for svn. > >> >> 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... >> > > I suspect the anomalies have not resulted from forced pushes, but from > local pulls and merges followed by innocuous pushes. So the key is > understanding how to ensure one's local branches have the desired > history before pushing to github. (And making sure one is pushing from > the correct source to the correct destination. Trying first with > --dry-run can help.)
Before pushing, I also recommend inspecting the history graph, either with "gitk --all" or "git log --oneline --graph --all". I try to remember to make sure the history graph looks the way I expect it should before I push anywhere. ------------------------------------------------------------------------------ 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
