On Thu, Jun 2, 2011 at 6:35 PM, Darren Dale <dsdal...@gmail.com> wrote: > On Thu, Jun 2, 2011 at 6:07 PM, Eric Firing <efir...@hawaii.edu> 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
