Thanks Eric; this is what I was looking for, and it's a shame that there
seems to be no way to accomplish this without cherrypicking a commit or
range of commits. It seems that since v1.1.1 and master can be traced back
to some common ancestry, that git should be able to rewind and replay the
changes so that cherrypicking or reimplementing wouldn't be necessary.
I've archived this email, though, so that I can use it at the appropriate
time.
For the immediate need, I was going to add the keyword 'bbox_size' to
Annotations, so that the user can optionally specify the box size around an
annotation...also was going to add additional boxstyles for Annotations, so
that one could use a circle, ellipse, or any other type of patch to enclose
the annotation. This would be useful for flowcharting and any other use
where the user wants a "patch with text inside".
As it stands, though I can only get 95% of this done...I can't seem to get
the placement of the patch correct when the text is rotated, unless
ha='center' and va='center', or if rotation_mode='anchor'. So since I
would cause a regression here, I guess it's off the table.
On Sun, Aug 12, 2012 at 11:23 PM, Eric Firing <efir...@hawaii.edu> wrote:
> 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
>
--
Daniel Hyams
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
