Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commite592e7a

Browse files
committed
Addressing more review suggestions
1 parent7c1e037 commite592e7a

File tree

3 files changed

+66
-75
lines changed

3 files changed

+66
-75
lines changed

‎doc/devel/coding_guide.rst‎

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -48,10 +48,9 @@ rules before submitting a pull request:
4848
* All public methods should have informative docstrings with sample usage when
4949
appropriate. Use the:ref:`docstring standards<writing-docstrings>`.
5050

51-
* Each high-level plotting function should have a simple example in the
52-
``Example`` section of the docstring. This should be as simple as possible
53-
to demonstrate the method. More complex examples should go in the
54-
``examples`` tree.
51+
* For high-level plotting functions, consider adding a simple example either in
52+
the ``Example`` section of the docstring or the
53+
:ref:`examples gallery<gallery>`.
5554

5655
* Changes (both new features and bugfixes) should have good test coverage. See
5756
:ref:`testing` for more details.

‎doc/devel/development_setup.rst‎

Lines changed: 19 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -37,10 +37,24 @@ You can retrieve the latest sources with the command (see
3737
.. _SSH key:https://docs.github.com/en/authentication/connecting-to-github-with-ssh
3838

3939
This will place the sources in a directory:file:`matplotlib` below your
40-
current working directory. Change into this directory::
40+
current working directory, and set up the `upstream remote<https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories>`__
41+
to point to the Matplotlib main repository. Change into this directory before
42+
continuing::
4143

4244
cd matplotlib
4345

46+
..note::
47+
48+
For more information on ``git`` and ``GitHub``, check the following resources.
49+
50+
* `Git documentation<https://git-scm.com/doc>`_
51+
* `Git-Contributing to a Project<https://git-scm.com/book/en/v2/GitHub-Contributing-to-a-Project>`_
52+
* `Introduction to GitHub<https://lab.github.com/githubtraining/introduction-to-github>`_
53+
*:ref:`using-git`
54+
*:ref:`git-resources`
55+
* `Installing git<https://git-scm.com/book/en/v2/Getting-Started-Installing-Git>`_
56+
* https://tacaswell.github.io/think-like-git.html
57+
* https://tom.preston-werner.com/2009/05/19/the-git-parable.html
4458

4559
.. _dev-environment:
4660

@@ -91,30 +105,8 @@ After you have cloned the repo change into the matplotlib directory.
91105

92106
Remember to activate the environment whenever you start working on Matplotlib.
93107

94-
<<<<<<< HEAD
95-
Install additional development dependencies
96-
===========================================
97-
See:ref:`development-dependencies`.
98-
99-
=======
100-
<<<<<<< HEAD
101-
>>>>>>> e998d58f3c (Refactoring gitwash)
102-
Install Matplotlib in editable mode
103-
===================================
104-
=======
105-
..seealso::
106-
107-
* `Git documentation<https://git-scm.com/doc>`_
108-
* `Git-Contributing to a Project<https://git-scm.com/book/en/v2/GitHub-Contributing-to-a-Project>`_
109-
* `Introduction to GitHub<https://lab.github.com/githubtraining/introduction-to-github>`_
110-
*:ref:`using-git`
111-
*:ref:`git-resources`
112-
* `Installing git<https://git-scm.com/book/en/v2/Getting-Started-Installing-Git>`_
113-
114-
115108
Installing Matplotlib in editable mode
116109
======================================
117-
>>>>>>> 0e759d3ee8 (Refactoring gitwash)
118110
Install Matplotlib in editable mode from the:file:`matplotlib` directory
119111
using the command ::
120112

@@ -128,6 +120,10 @@ true for ``*.py`` files. If you change the C-extension source (which might
128120
also happen if you change branches) you will have to re-run
129121
``python -m pip install -ve .``
130122

123+
Install additional development dependencies
124+
===========================================
125+
See:ref:`development-dependencies`.
126+
131127
Install pre-commit hooks (optional)
132128
===================================
133129
`pre-commit<https://pre-commit.com/>`_ hooks automatically check flake8 and

‎doc/devel/development_workflow.rst‎

Lines changed: 44 additions & 48 deletions
Original file line numberDiff line numberDiff line change
@@ -9,23 +9,21 @@ Development workflow
99
Workflow summary
1010
================
1111

12-
In what follows we'll refer to the upstream Matplotlib ``main`` branch, as
13-
"trunk".
12+
To keep your work well organized, with readable history, and in turn make it
13+
easier for project maintainers (that might be you) to see what you've done, and
14+
why you did it, we recommend the following:
1415

1516
* Don't use your ``main`` branch for anything. Consider deleting it.
16-
* When you are starting a new set of changes, fetch any changes from ``main``,
17-
and start a new *feature branch* from that.
18-
* Make a new branch for each separable set of changes — "one task, one
19-
branch".
17+
* Before starting a new set of changes, fetch all changes from
18+
``upstream/main``, and start a new *feature branch* from that.
19+
* Make a new branch for each feature or bug fix — "one task, one branch".
2020
* Name your branch for the purpose of the changes - e.g.
2121
``bugfix-for-issue-14`` or ``refactor-database-code``.
2222
* If you get stuck, reach out on Gitter or
2323
`discourse<https://discourse.matplotlib.org>`__.
24-
* Ask for a code review!
25-
26-
This way of working helps to keep work well organized, with readable history.
27-
This in turn makes it easier for project maintainers (that might be you) to see
28-
what you've done, and why you did it.
24+
* When your ready or need feedback on your code, open a pull-request so that the
25+
Matplotlib developers can give feedback and eventually include your suggested
26+
code into the ``main`` branch.
2927

3028
..note::
3129

@@ -35,21 +33,19 @@ what you've done, and why you did it.
3533

3634
.. _deleting main on github:https://matthew-brett.github.io/pydagogue/gh_delete_master.html
3735

38-
.. _update-mirror-trunk:
36+
.. _update-mirror-main:
3937

40-
Update the mirror oftrunk
41-
==========================
38+
Update the mirror ofmain
39+
=========================
4240

4341
First make sure you have done:ref:`linking-to-upstream`.
4442

45-
From time to time you should fetch the upstream(trunk)changes from github::
43+
From time to time you should fetch the upstream changes from github::
4644

4745
git fetch upstream
4846

4947
This will pull down any commits you don't have, and set the remote branches to
50-
point to the right commit. For example, 'trunk' is the branch referred to by
51-
(remote/branchname) ``upstream/main`` - and if there have been commits since
52-
you last checked, ``upstream/main`` will change after you do the fetch.
48+
point to the right commit.
5349

5450
.. _make-feature-branch:
5551

@@ -69,17 +65,17 @@ what the changes in the branch are for. For example ``add-ability-to-fly``, or
6965

7066
::
7167

72-
# Update the mirror oftrunk
68+
# Update the mirror ofmain
7369
git fetch upstream
74-
# Make new feature branch starting at currenttrunk
70+
# Make new feature branch starting at currentmain
7571
git branch my-new-feature upstream/main
7672
git checkout my-new-feature
7773

7874
Generally, you will want to keep your feature branches on your public GitHub
7975
fork of Matplotlib. To do this, you ``git push`` this new branch up to your
80-
github repo. Generally (if you followed the instructions in these pages, and by
81-
default), git will have a link to yourgithub repo, called ``origin``. You push
82-
up to your ownrepo on github with::
76+
GitHub repo. Generally (if you followed the instructions in these pages, and by
77+
default), git will have a link to yourfork of the GitHub repo, called
78+
``origin``. You pushup to your ownfork with::
8379

8480
git push origin my-new-feature
8581

@@ -89,7 +85,7 @@ In git >= 1.7 you can ensure that the link is correctly set by using the
8985
git push --set-upstream origin my-new-feature
9086

9187
From now on git will know that ``my-new-feature`` is related to the
92-
``my-new-feature`` branch in thegithub repo.
88+
``my-new-feature`` branch in theGitHub repo.
9389

9490
.. _edit-flow:
9591

@@ -145,8 +141,8 @@ In more detail
145141
.. _tangled working copy problem:http://2ndscale.com/rtomayko/2008/the-thing-about-git
146142

147143

148-
Ask for your changes to be reviewed or merged
149-
=============================================
144+
Open a pull request
145+
===================
150146

151147
When you are ready to ask for someone to review your code and consider a merge,
152148
`submit your Pull Request (PR)<https://docs.github.com/pull-requests>`_.
@@ -174,55 +170,55 @@ To see a linear list of commits for this branch::
174170

175171
git log
176172

177-
.. _rebase-on-trunk:
173+
.. _rebase-on-main:
178174

179-
Rebasing ontrunk
180-
-----------------
175+
Rebasing on``upstream/main``
176+
-----------------------------
181177

182178
Let's say you thought of some work you'd like to do. You
183-
:ref:`update-mirror-trunk` and:ref:`make-feature-branch` called
184-
``cool-feature``. At this stage trunk is at some commit, let's call it E. Now
185-
you make some new commits on your ``cool-feature`` branch, let's call them A, B,
186-
C.Maybe your changes take a while, or you come back to them after a while. In
187-
the meantime,trunk has progressed from commit E to commit (say) G:
179+
:ref:`update-mirror-main` and:ref:`make-feature-branch` called
180+
``cool-feature``. At this stage, ``main`` is at some commit, let's call it E.
181+
Nowyou make some new commits on your ``cool-feature`` branch, let's call them
182+
A, B,C. Maybe your changes take a while, or you come back to them after a
183+
while. Inthe meantime,``main`` has progressed from commit E to commit (say) G:
188184

189185
..code-block::none
190186
191187
A---B---C cool-feature
192188
/
193-
D---E---F---Gtrunk
189+
D---E---F---Gmain
194190
195-
At this stage you consider mergingtrunk into your feature branch, and you
191+
At this stage you consider merging``main`` into your feature branch, and you
196192
remember that this here page sternly advises you not to do that, because the
197193
history will get messy. Most of the time you can just ask for a review, and not
198-
worry thattrunk has got a little ahead. But sometimes, the changes in trunk
199-
might affect your changes, and you need to harmonize them. In this situation
200-
you may prefer to do a rebase.
194+
worry that``main`` has got a little ahead. But sometimes, the changes in
195+
``main``might affect your changes, and you need to harmonize them. In this
196+
situationyou may prefer to do a rebase.
201197

202-
rebase takes your changes (A, B, C) and replays them as if they had been made to
203-
the current state of ``trunk``. In other words, in this case, it takes the
204-
changes represented by A, B, C and replays them on top of G. After the rebase,
205-
your history will look like this:
198+
``rebase`` takes your changes (A, B, C) and replays them as if they had been
199+
made tothe current state of ``main``. In other words, in this case, it takes
200+
thechanges represented by A, B, C and replays them on top of G. After the
201+
rebase,your history will look like this:
206202

207203
..code-block::none
208204
209205
A'--B'--C' cool-feature
210206
/
211-
D---E---F---Gtrunk
207+
D---E---F---Gmain
212208
213209
See `rebase without tears`_ for more detail.
214210

215211
.. _rebase without tears:https://matthew-brett.github.io/pydagogue/rebase_without_tears.html
216212

217-
To do a rebase ontrunk::
213+
To do a rebase on``upstream/main``::
218214

219-
#Update the mirror of trunk
215+
#Fetch changes from upstream/main
220216
git fetch upstream
221217
# go to the feature branch
222218
git checkout cool-feature
223219
# make a backup in case you mess up
224220
git branch tmp cool-feature
225-
# rebase cool-feature ontotrunk
221+
# rebase cool-feature ontomain
226222
git rebase --onto upstream/main upstream/main cool-feature
227223

228224
In this situation, where you are already on branch ``cool-feature``, the last
@@ -237,7 +233,7 @@ When all looks good you can delete your backup branch::
237233
If it doesn't look good you may need to have a look at
238234
:ref:`recovering-from-mess-up`.
239235

240-
If you have made changes to files that have also changed intrunk, this may
236+
If you have made changes to files that have also changed in``main``, this may
241237
generate merge conflicts that you need to resolve - see the `git rebase`_ man
242238
page for some instructions at the end of the "Description" section. There is
243239
some related help on merging in the git user manual - see `resolving a merge`_.

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp