Doc build is failing with a missing file .. plot:: mpl_examples/mplot3d/contourf3d_demo2.py I can work around it, but this should get added... JDH
It was added a while back, unless I only added it to the master...? Ben Root On Thu, Apr 14, 2011 at 4:39 PM, John Hunter <jd...@gm...> wrote: > Doc build is failing with a missing file > > .. plot:: mpl_examples/mplot3d/contourf3d_demo2.py > > I can work around it, but this should get added... > > JDH >
On Apr 14, 2011, at 5:08 PM, Benjamin Root <ben...@gm...> wrote: > It was added a while back, unless I only added it to the master...? > Could be. It appears the mplot3d tutorial rest document in the release branch refers to it, but it is not committed in the branch. You can either commit the file or remove the doc reference from the branch.
On Thu, Apr 14, 2011 at 5:54 PM, John Hunter <jd...@gm...> wrote: > > > > > On Apr 14, 2011, at 5:08 PM, Benjamin Root <ben...@gm...> wrote: > > It was added a while back, unless I only added it to the master...? > > > Could be. It appears the mplot3d tutorial rest document in the release > branch refers to it, but it is not committed in the branch. You can either > commit the file or remove the doc reference from the branch. > Ok, I just double-check what happened. I added a feature to mplot3d, and because it was a new feature, it was not added to the maintenance branch (although, that is the only reason why it was not backported). The missing demo requires that feature, therefore, it is the docs that are wrong in the v1.0.x branch. I am still in the middle of my work (although the load has lightened today), and so I haven't been git-minded in a while. Would a change to the v1.0.x branch "stay" on the v1.0.x branch, or is there something I have to do to prevent subsequent merges from going into master? Ben Root
Benjamin Root <ben...@gm...> writes: > Would a change to the v1.0.x branch "stay" on the v1.0.x branch, or is > there something I have to do to prevent subsequent merges from going > into master? Since v1.0.x is supposed to be merged into master frequently, your change would propagate into master. To prevent it: 1. make sure v1.0.x is merged into master (usually it is, but if not, start by doing that merge) 2. merge your change to v1.0.x 3. merge v1.0.x to master with git checkout master git merge --strategy=ours v1.0.x This means that (1) the merge commit on top of v1.0.x will be in master's history, so it will not be merged again; (2) the merge is done by selecting the version of each file that is already in master, so the contents of master do not change. -- Jouni K. Seppänen http://www.iki.fi/jks
On Fri, Apr 15, 2011 at 9:27 AM, Jouni K. Seppänen <jk...@ik...> wrote: > Benjamin Root <ben...@gm...> writes: > > > Would a change to the v1.0.x branch "stay" on the v1.0.x branch, or is > > there something I have to do to prevent subsequent merges from going > > into master? > > Since v1.0.x is supposed to be merged into master frequently, your > change would propagate into master. To prevent it: > > 1. make sure v1.0.x is merged into master (usually it is, but > if not, start by doing that merge) > 2. merge your change to v1.0.x > 3. merge v1.0.x to master with > > git checkout master > git merge --strategy=ours v1.0.x > > This means that (1) the merge commit on top of v1.0.x will be in > master's history, so it will not be merged again; (2) the merge is done > by selecting the version of each file that is already in master, so the > contents of master do not change. > > -- > Jouni K. Seppänen > http://www.iki.fi/jks > > > Ok, thanks, I did that, and everything looks ok. I pushed the fixes up. Hopefully, the next merge doesn't screw things up. Ben