That looks good!
Thanks for the patch.

Looking through _axes.py, I see that sometimes True, False, and None are quoted as True, etc. in the parameter descriptions. Also, default values of optional parameters are sometimes given on the first line, following the optional keyword.

Is there a preferred style for these things?

Sorry, this needs a rebase; those call signatures were removed in v2.x which I just merged back into master, so there are now conflicts on this PR.

@cfackler We don't have a consensus on this yet.

Rebased pull request and also converted set_ylim() docstring.

Should I open a new pull request for additional docstring updates to the axes class, or continue to update this one?

It's pretty much up to you! As long as our documentation builds, I am happy to merge them as they come. But if you prefer to continue working on this PR, I'll be happy to review it once you are done.

In general, our docstrings need some love, so don't feel limited to the ones I added on that ticket. If you prefer, you can also work on one of our more complicated ticket, and update the docstrings while you read the code to figure out how to accomplish the tasks in that ticket.

Well shoot. I messed up my branch here somehow.

Did you by any chance rebase something recently?

Yes, I believe I typed an incorrect rebase. Git was not letting me push my last changes and saying I was behind the remote counterpart.

There are two options:

• reverting the rebase but if you committed after that, I am not sure what happens.
• creating a new branch from master and cherry-picking the commits.

The safer is probably the latter, and I can easily walk you through it if you want.

Ugh, yeah, my commit 6c5a44e was after the rebase. Sounds like the cherry-picking is probably the way to go. Sorry :( and thanks for the help!

Typing the following sets of commands should work:

• git checkout -b update_axes_docstring_fixed master supposing that master is up-to-date with the latest version of master. That creates a branch called update_axes_docstring_fixed and moves into that branch.
• git cherry-pick 6c601c0 will cherry-pick commit 6c601c0 into this new branch
• git cherry-pick 6ef07e7 same for 6ef07e7
• git cherry-pick 6c5a44e etc…

And the safest is probably to push into a new branch though you could also update this remote branch by doing:

• git push --force origin update_axes_docstring_fixed:update_axes_docstring

Cool! I've never used cherry-pick before. I now have update-axes-docstrings-fixed as a newly-pushed remote branch. Should I open a new PR based on that branch and close this one?

Thanks again for your help!

Sounds good! This way you'll have a clean start.
Before deleting anything, let's make sure the new branch is fine.

What happened was, you had this:

--- A <-master
    \- B --- C <- update-axes-docstrings

and pulled new updates:

--- A --- D --- E <- master
    \- B --- C <- update-axes-docstrings

then rebased:

--- A --- D --- E --- B' --- C' <- update-axes-docstrings
                ^ master

but GitHub still had the old thing, so when you tried to push, git said "Wait, what happened to B and C? Maybe you forgot them, so you should pull them down."

By following git's advice, you pull down the old B and C again, getting:

--- A --- D --- E --- B' --- C'
    \           ^ master       \
     \- B --- C --------------- M <- update-axes-docstrings

Then it's a bit unclear to me, but I think another rebase with the original B, C and new B', C' and the new-on-master D, E getting muddled together.

Should I open a new PR based on that branch and close this one?

It's not strictly necessary as you can force push here. In fact, we could do the rebase as well since you've ticked the box on the right allowing it, but that does mean you have to reset your own local copy with these.

BTW, when the rebase has got your commits all messed around, it's great to use a GUI like gitg to view the commit graph, but if you don't have that available, you can use git log --graph --decorate. Maybe also add in --all to see the branches on GitHub as well.

@NelleV PR 7389 should be what I had intended for this evening's commit to do. :)

@QuLogic That sounds exactly like the rebase I did before commit 6c601c0. But, when I went to push the changes currently committed as 6c5a44e, git complained that I was behind the remote counterpart. That's when I screwed up with a wrong rebase command.

@QuLogic I'm happy to reset my local copy as needed if you'd like to rebase properly. Thanks for the git GUI tips; I tried to take a look at it in gitk but it sounds like I should look for a better option.

Thanks @cfackler !

No need, the other PR is already open. You can delete this branch if you want.