On 11/30/2014 08:30 AM, Donald Stufft wrote:
On Nov 30, 2014, at 2:08 AM, Larry Hastings <la...@hastings.org
<mailto:la...@hastings.org>> wrote:
On 11/29/2014 04:37 PM, Donald Stufft wrote:
On Nov 29, 2014, at 7:15 PM, Alex Gaynor<alex.gay...@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:
1. hg supports this workflow (or a reasonable fascimile), which may
lessen the need for this PEP.
2. 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,
I was about to point that bookmark are no longer an extension for more
than 3 years, but someone was faster than me.
But I would like to reply a bit more on this extension FUD. There is
three kind of Mercurial feature:
1) The one in Mercurial core
2) The one in official extension
3) the one in third party extension
(1) and (2) Have the -same- level of support and stability. All of them
are part of the same repo and same test suite, offer the same backward
compatibility promise and are installed as part of the same package.
Official extensions are usually not in core for various reasons:
1) It is exotic feature (eg: communication bugzilla extension)
2) Nobody did the work to move it into core (unfortunatly) (eg: progress
bar extension) (similar situation: how long did it took to get pip
shipped with python?)
3) We think it is a important feature but we are not happy with the
current UX and would like somethign better before moving it into core
(eg: histedit)
Not using official extensions because they are extensions is similar to
not use the python standard library because "They are modules, not part
of the core language"
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.
Your workflow issue does not seems to be particularly tied to the tool
(Mercurial) itself but more to (1) very partial usage of the tool (2)
current project workflow. It would not be hard to (1) use the tools in a
less painful way (2) rethink project workflow to reduce the pain. This
seems orthogonal to changing the tool.
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 which also supports
Mercurial
and use that.
(note: Yes Manual upload of patch is terrible and tracking email by
patch is terrible too. But github is fairly bad at doing pull request.
It emphasis the final result instead of the actual pull request content.
Encouraging massive patches and making the history muddier.)
This PEP says that git and Github have the popular vote, which is extremely
compelling as a feature because:
Sure, Git//Github is more popular than Mercurial nowaday. But can I
point to the irony of Python using the "more popular" argument? If most
of people here would have seen this definitive argument, they would been
currently writing Java code instead of discussing Python on this list.
--
Pierre-Yves David
_______________________________________________
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
