On 06/02/2011 12:35 PM, Darren Dale 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.
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://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
