On 2012/08/12 3:34 PM, Daniel Hyams wrote: > > I was wanting to add a feature to matplotlib...one that I would use in > my application. I also want to contribute the feature back. I'm > personally using version 1.1.1 of matplotlib. Disclaimer...I only know > enough about git to be dangerous. > > So is it best to branch from v1.1.1, implement the feature, and then try > to rebase to master? Or is it best to branch from master, implement the > feature, and then (somehow) backport the patch to the v1.1.1 tagged version?
Mike answered for the case where you are making a bugfix that really does go in v1.1.x. I think that even there, what he is recommending is a bit different from what you have in mind: he is saying to branch from an up-to-date v1.1.x, not from v1.1.1. Similarly, for the case you have in mind, the pull request should be for a change relative to a recent enough point on the master branch that it can be merged cleanly, and with no unexpected side-effects. It sounds like what you are trying to do is maintain your own branch off of the v1.1.1 tagged version, with only your own features added. I don't think there is any single best way to do this; it depends on how you work, and on what sorts of changes you are making. Developing your change in your feature branch off of v1.1.1 is perfectly reasonable, since that is where you are normally working, and that is where you need it to work. To propagate it upstream, you do need to either cherry-pick it, or reimplement it, relative to recent master. Re-implementing it can be simpler in some cases--easier to see what is going on! I had been thinking "rebase", but this is not correct; you don't want to *remove* your commits from your branch off of v1.1.1, you want to *reproduce* them, or their net effect, in a *new* topic branch off of up-to-date master. It would go something like this. Assume "upstream" is the remote pointing to the main mpl repo, and "origin" is your github repo. Assume your changes are in a topic branch called "dh_topic_stable", off of v1.1.1. Find the commit numbers in dh_topic_stable that you need to propagate, say "a0b123fed" and "df237abc". git fetch upstream git checkout -b dh_topic upstream/master git cherry-pick a0b123fed df237abc # build and test; maybe add documentation and test commits git push origin dh_topic Then make your pull request against mpl master. For seeing what is in a repo, and what happens at each step of the way, I find qgit helpful. Invoke as "qgit --all". You need to hit the refresh button after each command-line git call. Eric > > Whatever the best choice is, what would the procedure look like to > accomplish this? > > -- > Daniel Hyams > dhy...@gmail.com <mailto:dhy...@gmail.com> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
