Re: [matplotlib-devel] v1.0.x branch seems confused
On Wed, Jun 1, 2011 at 6:20 PM, Matthew Brett wrote: > Hi, > > On Wed, Jun 1, 2011 at 4:06 PM, Eric Firing wrote: > > On 06/01/2011 12:38 PM, Matthew Brett wrote: > >> Hi, > >> > >> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing > 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? Ben Root -- 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
Re: [matplotlib-devel] v1.0.x branch seems confused
Mike, On Wed, Jun 1, 2011 at 2:26 PM, Michael Droettboom wrote: > Yes, it seems that the v1.0.x got hosed somehow back in early May. Eric > Firing did some spelunking and traced it to a push I made, but I'm not sure > what I did wrong, and I'm even less sure how to fix it. If someone with > more git-fu wants to investigate and repair it, that would be fantastic, but > I'm afraid to touch it myself. I'm taking a guess here: gtk_crash was branched off of master, but perhaps the pull request was registered against the v1.0.x branch. In any case, gtk_crash was merged with v1.0.x. I've done something similar myself, but I always merge into a clean local copy of v1.0.x or master and inspect the history graph, so I noticed my mistake before I actually pushed the changes. I have a little time now, maybe something can be done to correct it. -- 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
Re: [matplotlib-devel] v1.0.x branch seems confused
On Thu, Jun 2, 2011 at 4:46 PM, Benjamin Root wrote: > > > On Wed, Jun 1, 2011 at 6:20 PM, Matthew Brett > wrote: >> >> Hi, >> >> On Wed, Jun 1, 2011 at 4:06 PM, Eric Firing wrote: >> > On 06/01/2011 12:38 PM, Matthew Brett wrote: >> >> Hi, >> >> >> >> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing >> >> 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.s
Re: [matplotlib-devel] bug in plot_basedir and changed default directory in plot_directive?
On Tue, May 31, 2011 at 9:18 PM, Skipper Seabold wrote: > It seems that this commit [1] changed the default directory for the > sphinx plots directory (now needs to be alongside the directive and > not in the directory above it?) and now our project's docs will not > build across different versions of matplotlib without some magic. So I > tried setting > > from os.path import dirname, abspath > plot_basedir = dirname(dirname(abspath(__file__))) > > in our sphinx conf.py. We have source/conf.py and plots/ is in the > parent directory of source for the directive plot:: > plots/some_file.py. However, now I get this error [2] and this > traceback [3]. It seems the build/plot_directive folder is created > before a subsequent call to os.makedir. If I move plots to its > expected default location and then set the plot_basedir manually it's > fine. Is this a bug or user error? Is there some reason our plots > directory can't be in the parent directory of source? > > [1] > https://github.com/matplotlib/matplotlib/commit/a205f5460f13d47aa5b5fad662005c382dd096ee > [2] http://pastebin.com/KQp11CiS > [3] http://pastebin.com/4LY1Pt1Q > > Skipper > Ok, there were two things going on here. First, when build_dir is created it is joined with a relative path that will include '..' if necessary. matplotlib.cbook.mkdirs does not handle this correctly, but os.makedirs does. Is there a good reason to keep cbook.mkdirs? This problem could also be solved with a call to os.path.normpath, which is needed for the next issue anyway. Second, since we call our source folder plots, there is a conflict when trying to copy it over at the end to the destination directory. This commit adds a call to os.path.normpath, replaces cbook.mkdirs with os.makedirs, and only copies the plots to the destination directory if there's a need. https://github.com/matplotlib/matplotlib/pull/132 Skipper -- 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
Re: [matplotlib-devel] bug in pyplot.subplot if squeeze is False
On Tue, May 31, 2011 at 9:25 PM, Skipper Seabold wrote: > I filed a bug report here [1]. If squeeze is false, ret never gets defined. > > https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/pyplot.py#L794 > > Skipper > > [1] > https://sourceforge.net/tracker/?func=detail&aid=3309967&group_id=80706&atid=560720 > > PS. Should I ping the user or devel list with bug reports (or neither)? > I went ahead and patched this, so our tests would run and our docs would build with matplotlib master. I just made it how it was in the 1.0.1 tag. https://github.com/matplotlib/matplotlib/pull/133 Skipper -- 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
Re: [matplotlib-devel] v1.0.x branch seems confused
On Thu, Jun 2, 2011 at 5:00 PM, Darren Dale wrote: > On Thu, Jun 2, 2011 at 4:46 PM, Benjamin Root wrote: >> >> >> On Wed, Jun 1, 2011 at 6:20 PM, Matthew Brett >> wrote: >>> >>> Hi, >>> >>> On Wed, Jun 1, 2011 at 4:06 PM, Eric Firing wrote: >>> > On 06/01/2011 12:38 PM, Matthew Brett wrote: >>> >> Hi, >>> >> >>> >> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing >>> >> 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
Re: [matplotlib-devel] v1.0.x branch seems confused
On 06/02/2011 11:48 AM, Darren Dale wrote: [...] > > 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 Darren, That sounds very encouraging. If it is successful, I think we should use a different name and obliterate the current v1.0.x. If I understand correctly, doing a forced push instead would leave us open to having the repair undone. I don't see any advantage to it; but my git-ability is not high. Going forward, is there any good reason to retain all the old branches (transforms, 0.91.x etc.)? Don't the release tags provide adequate access to those branches? My sense is that merging them into master was not good from the standpoint of being able to read the graph and see what is really derived from what; but I don't know exactly what can be done about it. They certainly clutter up the output of "git branch -a" to no useful effect. Following along this line, does it perhaps make sense in the future to use cherry-picking instead of merging for propagating bug fixes between a maintenance or release branch and master? My uneducated sense is that it would leave a less confusing graph, and be less likely to result in errors. Eric -- 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
Re: [matplotlib-devel] v1.0.x branch seems confused
On Thu, Jun 2, 2011 at 6:07 PM, Eric Firing wrote: > On 06/02/2011 11:48 AM, Darren Dale wrote: > [...] >> >> 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 > > Darren, > > That sounds very encouraging. If it is successful, I think we should > use a different name and obliterate the current v1.0.x. If I understand > correctly, doing a forced push instead would leave us open to having the > repair undone. I don't see any advantage to it; but my git-ability is > not high. I just pushed a v1.0.x-cleanup branch to https://github.com/ddale/matplotlib . The next step would be to push it to v1.0.x-maint, and then merge v1.0.x-maint into master with --strategy=ours. At that point, I think we could delete the old v1.0.x branch, but I'd like to get a harrumph from another dev first. > Going forward, is there any good reason to retain all the old branches > (transforms, 0.91.x etc.)? I don't think we need the transforms branch. I kept it just for the sake of completeness during the svn->git migration. > Don't the release tags provide adequate > access to those branches? My sense is that merging them into master was > not good from the standpoint of being able to read the graph and see > what is really derived from what; but I don't know exactly what can be > done about it. They certainly clutter up the output of "git branch -a" > to no useful effect. There was actually a good reason for doing it this way. Each older maintenance branch was merged into the next newer one, and it was done with --strategy=ours (which basically means that any changes were ignored during the merge). We did this so that if someone applied a critical set of patches to an earlier maintenance branch, say 0.99.x, and wanted to merge it into v1.0.x, and then into master, it would be easy to do so without unintentionally pulling all of the other changes between 0.99.x and 1.0.x (for example) along with it. > Following along this line, does it perhaps make sense in the future to > use cherry-picking instead of merging for propagating bug fixes between > a maintenance or release branch and master? My uneducated sense is that > it would leave a less confusing graph, and be less likely to result in > errors. I would prefer to continue merging. I think its just a matter of getting in the habit of inspecting the history graph. But that's just my opinion. Thanks by the way for the pointer to qgit, I think it is much nicer than gitk. 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
Re: [matplotlib-devel] v1.0.x branch seems confused
On Thu, Jun 2, 2011 at 6:35 PM, Darren Dale wrote: > On Thu, Jun 2, 2011 at 6:07 PM, Eric Firing wrote: >> On 06/02/2011 11:48 AM, Darren Dale wrote: >> [...] >>> >>> 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 >> >> Darren, >> >> That sounds very encouraging. If it is successful, I think we should >> use a different name and obliterate the current v1.0.x. If I understand >> correctly, doing a forced push instead would leave us open to having the >> repair undone. I don't see any advantage to it; but my git-ability is >> not high. > > I just pushed a v1.0.x-cleanup branch to > https://github.com/ddale/matplotlib . The next step would be to push > it to v1.0.x-maint, and then merge v1.0.x-maint into master with > --strategy=ours. At that point, I think we could delete the old v1.0.x > branch, but I'd like to get a harrumph from another dev first. > >> Going forward, is there any good reason to retain all the old branches >> (transforms, 0.91.x etc.)? > > I don't think we need the transforms branch. I kept it just for the > sake of completeness during the svn->git migration. > >> Don't the release tags provide adequate >> access to those branches? My sense is that merging them into master was >> not good from the standpoint of being able to read the graph and see >> what is really derived from what; but I don't know exactly what can be >> done about it. They certainly clutter up the output of "git branch -a" >> to no useful effect. > > There was actually a good reason for doing it this way. Each older > maintenance branch was merged into the next newer one, and it was done > with --strategy=ours (which basically means that any changes were > ignored during the merge). We did this so that if someone applied a > critical set of patches to an earlier maintenance branch, say 0.99.x, > and wanted to merge it into v1.0.x, and then into master, it would be > easy to do so without unintentionally pulling all of the other changes > between 0.99.x and 1.0.x (for example) along with it. > >> Following along this line, does it perhaps make sense in the future to >> use cherry-picking instead of merging for propagating bug fixes between >> a maintenance or release branch and master? My uneducated sense is that >> it would leave a less confusing graph, and be less likely to result in >> errors. > > I would prefer to continue merging. I think its just a matter of > getting in the habit of inspecting the history graph. But that's just > my opinion. > > Thanks by the way for the pointer to qgit, I think it is much nicer than gitk. Actually, I feel fairly confident that this is a reasonable fix. I just pushed v1.0.x-maint, I pushed v1.0.x to my personal clone as a backup, and I deleted v1.0.x from the matplotlib repository. Ben, would you please rebase your mplot3d/minor_errors branch onto the new v1.0.x-maint branch? I'll post an announcement on mpl-dev about the change in maintenance branch. 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
Re: [matplotlib-devel] v1.0.x branch seems confused
On 06/02/2011 12:35 PM, Darren Dale wrote: > On Thu, Jun 2, 2011 at 6:07 PM, Eric Firing wrote: >> On 06/02/2011 11:48 AM, Darren Dale wrote: >> [...] >>> >>> 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 >> >> Darren, >> >> That sounds very encouraging. If it is successful, I think we should >> use a different name and obliterate the current v1.0.x. If I understand >> correctly, doing a forced push instead would leave us open to having the >> repair undone. I don't see any advantage to it; but my git-ability is >> not high. > > I just pushed a v1.0.x-cleanup branch to > https://github.com/ddale/matplotlib . The next step would be to push > it to v1.0.x-maint, and then merge v1.0.x-maint into master with > --strategy=ours. At that point, I think we could delete the old v1.0.x > branch, but I'd like to get a harrumph from another dev first. Dale, Thank you. > >> Going forward, is there any good reason to retain all the old branches >> (transforms, 0.91.x etc.)? > > I don't think we need the transforms branch. I kept it just for the > sake of completeness during the svn->git migration. > >> Don't the release tags provide adequate >> access to those branches? My sense is that merging them into master was >> not good from the standpoint of being able to read the graph and see >> what is really derived from what; but I don't know exactly what can be >> done about it. They certainly clutter up the output of "git branch -a" >> to no useful effect. > > There was actually a good reason for doing it this way. Each older I understand the rationale, but... > maintenance branch was merged into the next newer one, and it was done > with --strategy=ours (which basically means that any changes were > ignored during the merge). We did this so that if someone applied a which means that it is a fundamentally misleading merge--a merge in name only, not an indicator of what is in a given branch. > critical set of patches to an earlier maintenance branch, say 0.99.x, > and wanted to merge it into v1.0.x, and then into master, it would be > easy to do so without unintentionally pulling all of the other changes > between 0.99.x and 1.0.x (for example) along with it. I think the likelihood of anyone ever actually doing this is near zilch; we don't maintain old branches. And for the single current maintenance branch at any given time, cherry-picking bug fixes from maintenance to master or the reverse seems to me more explicit, less mysterious, and less likely to have unintended consequences than merging. > >> Following along this line, does it perhaps make sense in the future to >> use cherry-picking instead of merging for propagating bug fixes between >> a maintenance or release branch and master? My uneducated sense is that >> it would leave a less confusing graph, and be less likely to result in >> errors. > > I would prefer to continue merging. I think its just a matter of > getting in the habit of inspecting the history graph. But that's just > my opinion. I still don't agree. It looks to me like numpy is using the cherry-pick approach, not the merge approach, and the result is that each branch has a reasonably linear history that one can actually follow by eye, and easily see exactly what has been done. Compare numpy: http://currents.soest.hawaii.edu/hgstage/numpy_from_git/graph/9264?revcount=240 to mpl: http://currents.soest.hawaii.edu/hgstage/mpl_from_git/graph/6855?revcount=240 Even without the foulup, I think you would see that the merges from maintenance branches into subsequent branches and into master make it very hard to figure out what has actually been done on any given branch. Undoubtedly one *can* figure it out, as apparently you have just done; but it is not immediately clear from the graph. Eric > > Thanks by the way for the pointer to qgit, I think it is much nicer than gitk. > > 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:
[matplotlib-devel] v1.0.x RIP, long live v1.0.x-maint
Folks, We had some minor confusion with a merge a few weeks back, which pulled much of the master branch into the v1.0.x maintenance branch. I created a new v1.0.x-maint branch that rolled back all of the changes from that point on, and cherry-picked all of the changes that were actually intended for the v1.0.x branch. Please use v1.0.x-maint from now on. v1.0.x has been deleted from the repository (though I'll keep a local copy for a few weeks as a backup, just in case). If you have any changes that branched from v1.0.x after May 6 2011, please contact me off list so we can correctly apply those changes on top of v1.0.x-maint. 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
Re: [matplotlib-devel] v1.0.x branch seems confused
On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing wrote: > On 06/02/2011 12:35 PM, Darren Dale wrote: >> On Thu, Jun 2, 2011 at 6:07 PM, Eric Firing wrote: >>> Going forward, is there any good reason to retain all the old branches >>> (transforms, 0.91.x etc.)? >> >> I don't think we need the transforms branch. I kept it just for the >> sake of completeness during the svn->git migration. >> >>> Don't the release tags provide adequate >>> access to those branches? My sense is that merging them into master was >>> not good from the standpoint of being able to read the graph and see >>> what is really derived from what; but I don't know exactly what can be >>> done about it. They certainly clutter up the output of "git branch -a" >>> to no useful effect. >> > >> There was actually a good reason for doing it this way. Each older > > I understand the rationale, but... > >> maintenance branch was merged into the next newer one, and it was done >> with --strategy=ours (which basically means that any changes were >> ignored during the merge). We did this so that if someone applied a > > which means that it is a fundamentally misleading merge--a merge in name > only, not an indicator of what is in a given branch. No, it meant that all of the actual merges that we intended to do had already been done using svnmerge. But svn2git wasn't able to capture all of those relationships, so instead we did what we could at the time of the conversion. >> critical set of patches to an earlier maintenance branch, say 0.99.x, >> and wanted to merge it into v1.0.x, and then into master, it would be >> easy to do so without unintentionally pulling all of the other changes >> between 0.99.x and 1.0.x (for example) along with it. > > I think the likelihood of anyone ever actually doing this is near zilch; > we don't maintain old branches. aside from 1.0.x... > And for the single current maintenance > branch at any given time, cherry-picking bug fixes from maintenance to > master or the reverse seems to me more explicit, less mysterious, and > less likely to have unintended consequences than merging. I understand your position. >> >>> Following along this line, does it perhaps make sense in the future to >>> use cherry-picking instead of merging for propagating bug fixes between >>> a maintenance or release branch and master? My uneducated sense is that >>> it would leave a less confusing graph, and be less likely to result in >>> errors. >> >> I would prefer to continue merging. I think its just a matter of >> getting in the habit of inspecting the history graph. But that's just >> my opinion. > > I still don't agree. It looks to me like numpy is using the cherry-pick > approach, not the merge approach, and the result is that each branch has > a reasonably linear history that one can actually follow by eye, and > easily see exactly what has been done. Compare numpy: > > http://currents.soest.hawaii.edu/hgstage/numpy_from_git/graph/9264?revcount=240 > > to mpl: > > http://currents.soest.hawaii.edu/hgstage/mpl_from_git/graph/6855?revcount=240 Numpy appears to be applying all of their changes on master, and then cherry picking changes to apply to the maintenance branch. > Even without the foulup, I think you would see that the merges from > maintenance branches into subsequent branches and into master make it > very hard to figure out what has actually been done on any given branch. I strongly disagree. The only reason you get cleaner history graphs with cherry picking is because it doesn't graph the cherry picks! If you want to know what has been merged, you have to inspect the commit message in one branch and match it up with the commit message in another branch. How does that make it easier to figure out what has been done on any given branch? > Undoubtedly one *can* figure it out, as apparently you have just done; > but it is not immediately clear from the graph. I have another suggestion, relating to somebody's (your?) suggestion that we make more frequent releases. Development would be more robust if we were all branching from a commonly acknowledged reference point. For example, that might be v1.0.1 on the maintenance branch. The history graph would probably be cleaner as well. Then when a branch X is merged into maint, maybe we should be merging branch X into master as well, rather than merging v1.0.x into master. That would make it clearer what was actually being merged. Then, when v1.0.2 was tagged, we merge that into master (perhaps with strategy=ours if appropriate), and that becomes the new commonly acknowledged reference point on the master branch. 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/
Re: [matplotlib-devel] v1.0.x branch seems confused
Hi, On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale wrote: > On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing wrote: ... >> Even without the foulup, I think you would see that the merges from >> maintenance branches into subsequent branches and into master make it >> very hard to figure out what has actually been done on any given branch. > > I strongly disagree. The only reason you get cleaner history graphs > with cherry picking is because it doesn't graph the cherry picks! If > you want to know what has been merged, you have to inspect the commit > message in one branch and match it up with the commit message in > another branch. How does that make it easier to figure out what has > been done on any given branch? I think Eric's point is that it kind of feels (and looks) wrong to merge maintenance into master, rather than backporting fixes from master with cherry-picks. Maybe 'feels wrong' might be translatable as 'harder to think about' and therefore 'more error prone'? I can see the argument for doing it though. It is a common workflow? See you, 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. 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
Re: [matplotlib-devel] v1.0.x branch seems confused
Matthew, On Thu, Jun 2, 2011 at 8:17 PM, Matthew Brett wrote: > Hi, > > On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale wrote: >> On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing wrote: > ... >>> Even without the foulup, I think you would see that the merges from >>> maintenance branches into subsequent branches and into master make it >>> very hard to figure out what has actually been done on any given branch. >> >> I strongly disagree. The only reason you get cleaner history graphs >> with cherry picking is because it doesn't graph the cherry picks! If >> you want to know what has been merged, you have to inspect the commit >> message in one branch and match it up with the commit message in >> another branch. How does that make it easier to figure out what has >> been done on any given branch? > > I think Eric's point is that it kind of feels (and looks) wrong to > merge maintenance into master, rather than backporting fixes from > master with cherry-picks. Maybe 'feels wrong' might be translatable > as 'harder to think about' and therefore 'more error prone'? Maybe "feels wrong" translates to "unfamiliar", and has nothing to do with difficulty or potential for error. Git is a powerful tool. If we used a cherry-picking workflow (which I would not advocate), there would still be chances for error by inappropriately specifying hash ranges, for example. I think there is much more potential for error using cherry-picking. There are other advantages as well, see http://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow (note the warnings about rebasing, which are not relevant to this discussion) > I can > see the argument for doing it though. It is a common workflow? Yes, I believe it is a very common workflow. Before we made the git transition, I read about various workflows. What we are doing now is somewhat similar to what used to be done with svnmerge. I just googled "git workflow", and found http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html . See the section on "Merging Upwards": --- The "downwards graduation" discussed above cannot be done by actually merging downwards, however, since that would merge all changes on the unstable branch into the stable one. Hence the following: Rule: Merge upwards Always commit your fixes to the oldest supported branch that require them. Then (periodically) merge the integration branches upwards into each other. This gives a very controlled flow of fixes. If you notice that you have applied a fix to e.g. master that is also required in maint, you will need to cherry-pick it (using git-cherry-pick(1)) downwards. This will happen a few times and is nothing to worry about unless you do it very frequently. --- With cherry picking, imagine we get ready to cut a v1.0.2 release, and we want to know if all of the bug fixes that should be applied to the maintenance branch have been applied. How do we verify? Much easier is to apply them like the docs at kernel.org suggest, to the oldest supported branch that require them and then merge upwards. Then the history graph can tell you that the bug fixes in older versions have been applied to newer branches. Merging is going to happen anyway, whenever someone files a pull request. We have a good workflow, we just had a small mistake and have now overcome it. 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
Re: [matplotlib-devel] v1.0.x branch seems confused
Hi, On Thu, Jun 2, 2011 at 7:06 PM, Darren Dale wrote: > Matthew, > > On Thu, Jun 2, 2011 at 8:17 PM, Matthew Brett wrote: >> Hi, >> >> On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale wrote: >>> On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing wrote: >> ... Even without the foulup, I think you would see that the merges from maintenance branches into subsequent branches and into master make it very hard to figure out what has actually been done on any given branch. >>> >>> I strongly disagree. The only reason you get cleaner history graphs >>> with cherry picking is because it doesn't graph the cherry picks! If >>> you want to know what has been merged, you have to inspect the commit >>> message in one branch and match it up with the commit message in >>> another branch. How does that make it easier to figure out what has >>> been done on any given branch? >> >> I think Eric's point is that it kind of feels (and looks) wrong to >> merge maintenance into master, rather than backporting fixes from >> master with cherry-picks. Maybe 'feels wrong' might be translatable >> as 'harder to think about' and therefore 'more error prone'? > > Maybe "feels wrong" translates to "unfamiliar", and has nothing to do > with difficulty or potential for error. Ah no - I mean that the way I think most of think of bugfix workflow is that we fix in trunk and backport the fix to the maintenance branch. Here though you are fixing in the maintenance branch and _merging_ to trunk. The counter-argument is 'well think of it the other way round and it will be fine'. It's a little difficult to know if that's true I suppose. It's a funny kind of thing too, because it puts an extra constraint on the bugfix. For example, imagine a bugfix in maintenance, in some code that has crazy-changed in trunk. Now you have to decide if you try and merge it anyway, and basically do a rewrite as you fix the merge conflict. Or you could merge-ours on that commit and write a completely different fix on trunk. But that's getting a bit dark and magic. And so it imposes some slight what-will-happen brain overhead on the person writing the fix. > Git is a powerful tool. If we > used a cherry-picking workflow (which I would not advocate), there > would still be chances for error by inappropriately specifying hash > ranges, for example. I think there is much more potential for error > using cherry-picking. There are other advantages as well, see > http://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow > (note the warnings about rebasing, which are not relevant to this > discussion) > >> I can >> see the argument for doing it though. It is a common workflow? > > Yes, I believe it is a very common workflow. Ah - OK, I guess I had not seen it before. > Before we made the git transition, I read about various workflows. > What we are doing now is somewhat similar to what used to be done with > svnmerge. I just googled "git workflow", and found > http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html . > See the section on "Merging Upwards": Yes, I think I see why it would be attractive. > With cherry picking, imagine we get ready to cut a v1.0.2 release, and > we want to know if all of the bug fixes that should be applied to the > maintenance branch have been applied. How do we verify? Much easier is > to apply them like the docs at kernel.org suggest, to the oldest > supported branch that require them and then merge upwards. Then the > history graph can tell you that the bug fixes in older versions have > been applied to newer branches. I believe that the git log --cherry etc machinery is designed to deal with this case, but I haven't used it myself. I have to emphasize, the projects I've been involved with have fewer developers and smaller code-bases, 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. 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
