Thread: [matplotlib-devel] mplot3d/contourf3d_demo2.py not committed

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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