Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
DOC: add remote upstream#25828
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
DOC: add remote upstream#25828
Uh oh!
There was an error while loading.Please reload this page.
Conversation
story645 left a comment• edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Using 'remote' as shorthand for remote repository is a holdover from previous version so won't block, but wondering if it's worth it to add a sentence clarifying what a remote repository is and that the names for things are conventions. I know, we're not aiming to provide a "how to git" tutorial but I think this can be done very cleanly.
"remote" is git's term and part of the command you need to use. We have the link to GitHub'sManaging remote repositories, which gives a bit more detail to what these things are, and I think the fact that you pass the GitHub url makes it fairly intuitive what you are linking to. So I'm not sure what else this needs. I do in general have a preference for brevity though, which I'm aware is just a preference. So it's possible I'm just not seeing what you're seeing! |
| fork, and set up the ``upstream`` remote to point to the Matplotlib main | ||
| repository (see also `Managing remote repositories <https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories>`__.) | ||
| Change into this directory before continuing:: | ||
| current working directory and set up the ``origin`` remote to point to your own |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| current working directory and set upthe``origin``remote to point to your own | |
| current working directory and set upa remote repository``origin``pointing to your own |
Is this clearer? If so, same wording should be applied toupstream
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I really really really like this minor change - it addresses my concerns by explaining what the words are. Can I open a follow on PR to make this change?
I think the wording is fine as it is. |
building off ofmatplotlib#25828 and@timhoffm's comment, mostly reworded/movedthings (very little if any change in length) to try and make it moreexplicit that in this context origin and upstream are aliases forremote repositories.
building off ofmatplotlib#25828 and@timhoffm's comment, mostly reworded/movedthings (very little if any change in length) to try and make it moreexplicit that in this context origin and upstream are aliases forremote repositories.
building off ofmatplotlib#25828 and@timhoffm's comment, mostly reworded/movedthings (very little if any change in length) to try and make it moreexplicit that in this context origin and upstream are aliases forremote repositories.Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
PR summary
The dev guide currently suggests that cloning your fork will automatically add the upstream remote, but Ithink you have to add it manually.
PR checklist