On Nov 30, 2014, at 2:08 AM, Larry Hastings
wrote: On 11/29/2014 04:37 PM, Donald Stufft wrote:
On Nov 29, 2014, at 7:15 PM, Alex Gaynor
mailto:alex.gaynor@gmail.com wrote: Despite being a regular hg user for years, I have no idea how to create a local-only branch, or a branch which is pushed to a remote (to use the git term). I also don’t know how to do this.
Instead of collectively scratching your heads, could one of you guys do the research and figure out whether or not hg supports this workflow? One of the following two things must be true: hg supports this workflow (or a reasonable fascimile), which may lessen the need for this PEP. hg doesn't support this workflow, which may strengthen the need for this PEP. Saying "I've been using hg for years and I don't know whether it supports this IMPORTANT THING" is not a particularly compelling argument.
Comments like this make me feel like I didn’t explain myself very well in the PEP. While I do think that supporting this workflow via an extension is worse than supporting it in core, this isn’t why this PEP exists. The current workflow for contributing is painful, for the repositories this is talking about if I’m a non-comitter I have to email patches to a particular closed mailing list and then sit around and wait. The Pull Request based workflow is *massively* better than uploading/emailing patches around. So the question then becomes, if we're going to move to a PR based workflow how do we do it? PEP 474 says that we should install some software that works with Mercurial and supports Pull Requests. Another thread suggested that we should just use to bitbucket whicih also supports Mercurial and use that. This PEP says that git and Github have the popular vote, which is extremely compelling as a feature because: * Popularity is the one thing you can't replicate featurewise. This feature or that you can find a way to work something like it out. * With popularity comes the fact that people will already know the tooling involved and how to use it. This means that a new contributor whom already knows git will spend less time learning our specific toolset and more time being able to meaningfully contribute. * With popularity also comes transferability, If I don't currently know a VCS tool and I learn git (and github) for the sake of these repositories then that knowledge will directly transfer to greater than 60% of the top 100 projects on PyPI. * With popularity also comes an increased amount of people writing about it, asking questions, etc. This means that if I have a problem while using this tool I am more likely to find someone who already had this problem and they are more likely to have found someone to help them solve it than I am with a less popular tool. I'm not sure why people seem to try and focus on the fact that with this extension or that you can make Mercurial replicate git better when that isn't really the major point of the PEP at all. If Mercurial and git were neck in neck in terms of mindshare and bitbucket and Github were as well then this PEP probably wouldn't exist because on a techincal level I think the two tools are probably close enough. However when most of the world is using one tool and you're using another, that does represent a barrier to entry. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA