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. 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
