Spelling out a suggested local workflow for sending PRs?
Something that came up at work recently was instructing people on how best to configure local git clones for working with a "fork+PR" development model, where you have your own server-side fork for the project that you then use to submit pull requests. The trick is that there's an easy way to do this and a hard way, and it isn't immediately obvious which is which :) The easy way: * clone the upstream repo read-only * add your fork as an additional read/write remote: * e.g. "git remote add pr <URL of fork>" * work in a branch * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue" * publish via your fork, and then submit back to the main repo * "git push pr" * use the web UI to submit the PR The hard way: * clone your fork read/write * still work in topic branches * waste time keeping master in your fork up to date * forget the previous step, and submit PRs against a stale version of master I bring it up as when I first started using GitHub, the second way seemed intuitively obvious to me, but it actually makes things harder than they need to be. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Mar 6, 2016 at 1:27 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
The easy way:
* clone the upstream repo read-only * add your fork as an additional read/write remote: * e.g. "git remote add pr <URL of fork>" * work in a branch * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue" * publish via your fork, and then submit back to the main repo * "git push pr" * use the web UI to submit the PR
My workflow is exactly this, except that I have my own fork under the name "origin", and the upstream as "upstream". I then tell have these two commands (script/alias): branch: git fetch upstream master:master git checkout -b "$1" master push: git push -u origin `git symbolic-ref --short HEAD` To work on something: $ branch issueNNNN-whatever-branch-name ... make edits ... $ git commit ... $ push And then use the web UI to submit the PR. (There are alternatives to that, but I don't do enough to justify them.) The 'branch' command does a network transaction, so it'll take a bit of time. But it's the easiest way to make sure I never forget to update to the latest upstream. If in doubt, script it :) ChrisA
That should be added to the new devguide or a PEP. On Sun, Mar 06, 2016 at 12:27:52PM +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
Something that came up at work recently was instructing people on how best to configure local git clones for working with a "fork+PR" development model, where you have your own server-side fork for the project that you then use to submit pull requests. The trick is that there's an easy way to do this and a hard way, and it isn't immediately obvious which is which :)
The easy way:
* clone the upstream repo read-only * add your fork as an additional read/write remote: * e.g. "git remote add pr <URL of fork>" * work in a branch * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue" * publish via your fork, and then submit back to the main repo * "git push pr" * use the web UI to submit the PR
The hard way:
* clone your fork read/write * still work in topic branches * waste time keeping master in your fork up to date * forget the previous step, and submit PRs against a stale version of master
I bring it up as when I first started using GitHub, the second way seemed intuitively obvious to me, but it actually makes things harder than they need to be.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
I suggest that this be added to the new devguide, not a PEP, because there are many workflows that work for different people. One category of workflow is "make a clone on GitHub for each suggested patch, then nuke that clone and start over for the next patch". A different category of workflow is "clone on GitHub, clone from there to my local machine, and keep my local machine up-to-date with the origin so I can keep putting in patches easily". And there are other workflows that are supported by different small tooling. FWIW, I still don't know which I prefer. We are having this issue in the IETF, and it is clear that people don't all agree on what they prefer. I'm happy to write text up on this for the devguide when it gets time to do so. --Paul Hoffman On Sun, Mar 6, 2016 at 1:27 AM, Oleg Broytman <phd@phdru.name> wrote:
That should be added to the new devguide or a PEP.
On Sun, Mar 06, 2016 at 12:27:52PM +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
Something that came up at work recently was instructing people on how best to configure local git clones for working with a "fork+PR" development model, where you have your own server-side fork for the project that you then use to submit pull requests. The trick is that there's an easy way to do this and a hard way, and it isn't immediately obvious which is which :)
The easy way:
* clone the upstream repo read-only * add your fork as an additional read/write remote: * e.g. "git remote add pr <URL of fork>" * work in a branch * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue" * publish via your fork, and then submit back to the main repo * "git push pr" * use the web UI to submit the PR
The hard way:
* clone your fork read/write * still work in topic branches * waste time keeping master in your fork up to date * forget the previous step, and submit PRs against a stale version of master
I bring it up as when I first started using GitHub, the second way seemed intuitively obvious to me, but it actually makes things harder than they need to be.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
On 7 March 2016 at 01:23, Paul Hoffman <paul.hoffman@gmail.com> wrote:
I suggest that this be added to the new devguide, not a PEP, because there are many workflows that work for different people.
One category of workflow is "make a clone on GitHub for each suggested patch, then nuke that clone and start over for the next patch". A different category of workflow is "clone on GitHub, clone from there to my local machine, and keep my local machine up-to-date with the origin so I can keep putting in patches easily".
The audience here is folks that don't already have a preferred workflow for interesting with GitHub repos, so it's mainly that second one I want to advise people against using - having used it myself as my primary approach for working with GitHub repos until recently, I've found it to be a recipe for submitting PRs against a stale checkout of master, which then need to be rebased before they can be properly reviewed. That's a pain for both submitters and reviewers, but it's not obvious the problem exists until you've been using the approach for a while. The "ephemeral clone" approach is certainly an available option, but it's significantly more work for each patch than a persistent clone, and also doesn't tolerate having multiple PRs in flight at once, so I'm less worried about people choosing it naively without realising the additional hassle it causes. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, 6 Mar 2016 at 07:24 Paul Hoffman <paul.hoffman@gmail.com> wrote:
I suggest that this be added to the new devguide, not a PEP, because there are many workflows that work for different people.
Yep, this isn't policy but simply a suggestion, so it should go in the devguide.
One category of workflow is "make a clone on GitHub for each suggested patch, then nuke that clone and start over for the next patch". A different category of workflow is "clone on GitHub, clone from there to my local machine, and keep my local machine up-to-date with the origin so I can keep putting in patches easily". And there are other workflows that are supported by different small tooling.
FWIW, I still don't know which I prefer. We are having this issue in the IETF, and it is clear that people don't all agree on what they prefer.
I'm happy to write text up on this for the devguide when it gets time to do so.
Great! Thanks, Paul! My hope is that we get the devguide moved over early so that we can create a "github" branch to hold the GitHub-related changes so that as soon as cpython is ready to switch it will take nothing more than a merge of the branch into `master` to make the changes appear online. -Brett
--Paul Hoffman
On Sun, Mar 6, 2016 at 1:27 AM, Oleg Broytman <phd@phdru.name> wrote:
That should be added to the new devguide or a PEP.
On Sun, Mar 06, 2016 at 12:27:52PM +1000, Nick Coghlan < ncoghlan@gmail.com> wrote:
Something that came up at work recently was instructing people on how best to configure local git clones for working with a "fork+PR" development model, where you have your own server-side fork for the project that you then use to submit pull requests. The trick is that there's an easy way to do this and a hard way, and it isn't immediately obvious which is which :)
The easy way:
* clone the upstream repo read-only * add your fork as an additional read/write remote: * e.g. "git remote add pr <URL of fork>" * work in a branch * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue" * publish via your fork, and then submit back to the main repo * "git push pr" * use the web UI to submit the PR
The hard way:
* clone your fork read/write * still work in topic branches * waste time keeping master in your fork up to date * forget the previous step, and submit PRs against a stale version of master
I bring it up as when I first started using GitHub, the second way seemed intuitively obvious to me, but it actually makes things harder than they need to be.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
On Mar 06, 2016, at 12:27 PM, Nick Coghlan wrote:
The easy way:
* clone the upstream repo read-only * add your fork as an additional read/write remote: * e.g. "git remote add pr <URL of fork>" * work in a branch * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue" * publish via your fork, and then submit back to the main repo * "git push pr" * use the web UI to submit the PR
This is essentially what I do too, but with some differences in names. Chris mentioned naming the 'upstream' remote to point to the upstream repo, and 'origin' to name his clone. I do something different, but as a general recommendation to people who are coming to this workflow previously unscathed <wink> I like Chris's suggestion. I generally only name my issue branches after the issue number, e.g. "issue1234" since I can always go to the tracker to find details, and these shouldn't be long-lived branches anyway. I'd likely name a big feature branch differently. I think the essential bit of Nick's "easy way" is that you pretty much ignore your fork's master. It's just too much work to try to keep it sync'd against upstream master. Just do a pull of upstream master when you're starting something new, and push your branches to your own fork (and many people won't be able to push to upstream's repo anyway). Then use the web ui to create a pull request from that. Cheers, -Barry
On Tue, Mar 8, 2016 at 4:23 AM, Barry Warsaw <barry@python.org> wrote:
I think the essential bit of Nick's "easy way" is that you pretty much ignore your fork's master. It's just too much work to try to keep it sync'd against upstream master. Just do a pull of upstream master when you're starting something new, and push your branches to your own fork (and many people won't be able to push to upstream's repo anyway). Then use the web ui to create a pull request from that.
Yes, exactly. And you can tell git that (in .git/config or using the 'git config' command); effectively, if you "git checkout master; git pull", it'll pull in from upstream, not from origin (despite every other branch being tied to origin). Very handy. ChrisA
On Mon, 7 Mar 2016 at 09:23 Barry Warsaw <barry@python.org> wrote:
On Mar 06, 2016, at 12:27 PM, Nick Coghlan wrote:
The easy way:
* clone the upstream repo read-only * add your fork as an additional read/write remote: * e.g. "git remote add pr <URL of fork>" * work in a branch * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue" * publish via your fork, and then submit back to the main repo * "git push pr" * use the web UI to submit the PR
This is essentially what I do too, but with some differences in names. Chris mentioned naming the 'upstream' remote to point to the upstream repo, and 'origin' to name his clone. I do something different, but as a general recommendation to people who are coming to this workflow previously unscathed <wink> I like Chris's suggestion.
I generally only name my issue branches after the issue number, e.g. "issue1234" since I can always go to the tracker to find details, and these shouldn't be long-lived branches anyway. I'd likely name a big feature branch differently.
I think the essential bit of Nick's "easy way" is that you pretty much ignore your fork's master. It's just too much work to try to keep it sync'd against upstream master.
And honestly, who's going to care about your copy of `master`? :) If anyone works off your clone it's going to be for one of your branches, not `master`.
Just do a pull of upstream master when you're starting something new, and push your branches to your own fork (and many people won't be able to push to upstream's repo anyway). Then use the web ui to create a pull request from that.
And I think the other key is using "pr" as the remote's name so that you don't want to throttle GitHub for having you type the name constantly. You could do `git push --set-upstream pr` on the first push (or as soon as you create the branch), but you would need to do 9 pushes to break even with that many keystrokes.
On Tue, Mar 8, 2016 at 4:36 AM, Brett Cannon <brett@python.org> wrote:
Just do a pull of upstream master when you're starting something new, and push your branches to your own fork (and many people won't be able to push to upstream's repo anyway). Then use the web ui to create a pull request from that.
And I think the other key is using "pr" as the remote's name so that you don't want to throttle GitHub for having you type the name constantly. You could do `git push --set-upstream pr` on the first push (or as soon as you create the branch), but you would need to do 9 pushes to break even with that many keystrokes.
That's why I have my 'push' script. It's four keystrokes LESS than 'git push', and automatically sends a new branch to the appropriate remote :) ChrisA
On 8 Mar 2016 03:23, "Barry Warsaw" <barry@python.org> wrote:
On Mar 06, 2016, at 12:27 PM, Nick Coghlan wrote:.
I think the essential bit of Nick's "easy way" is that you pretty much ignore your fork's master. It's just too much work to try to keep it sync'd against upstream master.
Exactly, although it's actually "Vit's easy way" (my colleague Vit Ondruch proposed this as the recommended GitLab workflow for our current project at work, and it finally clicked for me what I'd been doing wrong all this time). That said, Chris's variant of just setting the upstream of the local clone's master branch to the upstream repo so "git checkout master && git pull" on master reads directly from upstream, while "git push" defaults to going to your fork, does sound intriguing - I'm going to try that on some of my existing projects where I made the original clone from my personal fork. Cheers, Nick.
On Mar 7, 2016, at 8:17 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
That said, Chris's variant of just setting the upstream of the local clone's master branch to the upstream repo so "git checkout master && git pull" on master reads directly from upstream, while "git push" defaults to going to your fork, does sound intriguing - I'm going to try that on some of my existing projects where I made the original clone from my personal fork.
This is what I do, it works very well in my experience. I also add a fetch line so that pull requests show up with refs and I can check them out locally. For example, here is my .git/config from one of my repositories: https://bpaste.net/show/2fd5a8dfe33e <https://bpaste.net/show/2fd5a8dfe33e> This means that my ``master`` branch tracks the upstream, the default origin is my fork, and I can checkout PRs locally using: $ git checkout pr/N # Checks out the PR as a branch tracking the PR $ git checkout -b whatever upstream/pr/N # checkout out the PR as a a new branch based on the PR. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 6 Mar 2016 12:27, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
Something that came up at work recently was instructing people on how
best to configure local git clones for working with a "fork+PR" development model, where you have your own server-side fork for the project that you then use to submit pull requests. The trick is that there's an easy way to do this and a hard way, and it isn't immediately obvious which is which :)
The easy way:
Oops, I left out the first step here: * create a personal fork of the upstream repo on GitHub
* clone the upstream repo read-only * add your fork as an additional read/write remote: * e.g. "git remote add pr <URL of fork>" * work in a branch * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue" * publish via your fork, and then submit back to the main repo * "git push pr" * use the web UI to submit the PR
The first step needs to be done once per project, and steps 2 & 3 once per project per client device. The actual patch development process is then a matter of ensuring your clone is up to date, creating a working branch, making & committing the changes, pushing to your personal fork, and then submitting the PR. Regards, Nick.
participants (7)
-
Barry Warsaw -
Brett Cannon -
Chris Angelico -
Donald Stufft -
Nick Coghlan -
Oleg Broytman -
Paul Hoffman