On Sun, Nov 23, 2014 at 2:38 PM, Donald Stufft <don...@stufft.io> wrote:
> > > On Nov 23, 2014, at 3:03 PM, Georg Brandl <g.bra...@gmx.net> wrote: > > > > The next point is that there is no easy way to change the target branch > of > > a pull request (on github or bitbucket). People will usually make > patches > > against the master branch unless told differently explicitly, which means > > that the pull request will also be against the master branch. Which > means, > > close the PR, ask submitter to resubmit against 3.x branch, or do it > > yourself. > > This in particular is not really true on Github at least. By default PRs > are > made against whichever branch you have configured as the default branch in > the Github UI. This does default to master but it doesn’t have to be, for > instance pip has this configured for the develop branch. Although I think > this specific point is moot because if things were on Git it’d probably > make > the most sense to have the default integration branch be ``master`` just > like > for the Hg repos they use default. > I'm liking the hubflow/gitflow git workflow extensions, where "trunk" is also develop. There are feature branches, hotfix branches, release branches, etc. # .git/config : "prefix": "v" git hf release start 0.1.0 echo "0.1.0" >> VERSION.txt git hf release finish 0.1.0 # (merges, release commit message, return to develop) These are some of the most helpful (git) branching diagrams I've ever seen: * https://datasift.github.io/gitflow/IntroducingGitFlow.html * http://www.infoq.com/articles/agile-version-control The support for tagging releases is helpful. (It's possible to host package releases for various platforms as GitHub releases). > > Even if someone makes a PR against the wrong branch, it “degrades” into > essentially the same UX as you have now, you can turn a PR into a patch by > adding a .patch or .diff to the end of the PR URL and then you have a patch > file. In additional github makes it easy to check out PRs directly with > only a > minor bit of one time configuration in your local clone. I can checkout > any PR > by doing ``git checkout pr/1`` (replacing 1 with whatever the number is). > > Honestly the worst part about someone sending a PR to the wrong branch is > it > degrades into the same terrible UX that *every* patch has to go through on > a hg.python.org repository right now. > In this respect, hg mq is tightly integrated, and written in Python. Patch Queue / build system of VCS integration could be helpful. * http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html * http://hgbook.red-bean.com/read/advanced-uses-of-mercurial-queues.html I agree that - [ ] Build status displayed on the PR [is an extremely useful feature for a code forge to offer] - [ ] Markdown/ReStructuredText Checkboxes are helpful * GitHub: Issues * BitBucket: PR Task Lists integrated with review. My mouse cursor tends to be near the scroll bar alot, as well. -- https://en.wikipedia.org/wiki/Forge_(software)#Technology https://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities > --- > Donald Stufft > PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com > -- Wes Turner https://westurner.github.io/
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
