On Thu, Jun 2, 2011 at 5:00 PM, Darren Dale <dsdal...@gmail.com> wrote: > 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.
I had another look at the history after rereading Pauli's email. I'm going to try the following on a temporary v1.0.x-cleanup branch: * "git reset --hard 0e6dad5230" * redo pull request 103 * cherry-pick the following commits off of the v1.0.x branch: - 069c21d - 53f8139e - de18d9ab2 - 91e7d980 - 0cc213b4fa - e7f1e83ace - 5c968a0ecdd That should bring the v1.0.x-cleanup branch back to where we thought it would be. I'll post the result in my fork as soon as it is ready, and request comment. At that point, we should decide if we want to rename it v1.0.x and force push, or rename it v1.0.x-maint (or whatever) and delete the current v1.0.x branch. Pauli, Jouni, any comments? Darren ------------------------------------------------------------------------------ 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
