On 06/01/2011 12:38 PM, Matthew Brett wrote: > Hi, > > On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing<efir...@hawaii.edu> wrote: >>> The current practice worked very nicely with SVN (IMHO), and I think it >> >> (I recall that Mike had to rescue us more than once from svnmerge >> confusions, at least during the earlier days.) > > I was just idly looking at the matplotlib network graph: > > https://github.com/matplotlib/matplotlib/network > > There seem to be lots of branches and cross merges ; the history of > 1.0.x is extremely confusing.
Agreed! > > I wonder whether it would be worthwhile to review git workflow? Yes. > > I like Pauli's edits to the numpy gitwash docs in numpy for this. > I've actually just merged these back into the gitwash main docs, > example build here: I will have to take a look; mpl did pull some version of gitwash into its doc build. > > http://matthew-brett.github.com/pydagogue/gitwash/git_development.html Thanks, I will take a look. > > Maybe the overall point is that git does require some thought to > history, and some rules-of-work, to avoid confusion. I think one of the problems is that documentation such as the Git book and at least early versions of gitwash, if I remember correctly, emphasize workflow for people who do not access the central repo directly. There has been much discussion on the lists of procedure for those who do push to central repos, but I am not sure to what extent it has gotten condensed down into a sufficiently simple set of rules and examples in the standard documentation. Maybe you and Pauli have done that now. > > I've been managing a maintenance branch for my much smaller nibabel > project without much trouble; I've just been doing the occasional > cherry-pick and rebase from trunk for bugfixes. In a way, this illustrates the difficulty: you describe a procedure for working with a maintenance branch that is completely different from the one we have been using (apart from the errors). What we have been doing is initiating bug fixes in the maintenance branch and then merging that branch to master. I'm sure either way can work fine, if one doesn't make mistakes. I'm not sure what the relative merits of the two methods are, in terms of simplicity, clarity, and robustness against errors. I think they result in very different graphs, correct? With your approach, the maintenance branch and master are separate lines, while with our approach, the merges keep pulling the branches together in the graph, even though their contents are steadily getting farther apart. Eric > > Cheers, > > Matthew ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
