On Thu, Jun 2, 2011 at 4:46 PM, Benjamin Root <ben.r...@ou.edu> wrote: > > > On Wed, Jun 1, 2011 at 6:20 PM, Matthew Brett <matthew.br...@gmail.com> > wrote: >> >> Hi, >> >> On Wed, Jun 1, 2011 at 4:06 PM, Eric Firing <efir...@hawaii.edu> wrote: >> > 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. >> >> If you like what you see, then the 'gitwash_dumper.py' script will >> pull a new copy into your repo... >> >> If you don't, then I'd love suggestions for improvements. >> >> >> 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. >> >> That's quite right, we did more or less assume that the maintainers >> were git experts, and yes, Pauli did fix that to some extent. The >> result, as ported back by me, is this page, which is new, and needs >> expanding: >> >> http://matthew-brett.github.com/pydagogue/gitwash/maintainer_workflow.html >> >> >> >> >> 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. >> >> I must confess that my git fu is not 10/10, but to me the idea of >> _merging_ the maintenance branch into trunk is very confusing. I >> mean, the trees should increasingly diverge, surely, so there will be >> more and more stuff you don't want to see back in trunk. At the >> moment, you have to trust git magic to correctly leave out the commits >> you don't want... >> >> See you, >> >> Matthew >> > > While this is all very important and we should definitely come to an > agreement about this, this still doesn't solve my issue at hand. I can not > build the docs in the v1.0.x branch, therefore we can not push out a > revision to the docs on sourceforge. Meanwhile, our website still has bad > links and is pointing users to download version 1.0.0 instead of version > 1.0.1 (which may explain why we still see some old bugs on the lists every > now and then). What do we want to do about my pull request for the docs?
Hold tight, lets see if anything can be done to back out the change. ------------------------------------------------------------------------------ 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
