Rip out mq instructions

[pitrou]

BPO	14466
Nosy	@orsenthil, @pitrou, @ned-deily, @ezio-melotti, @merwok, @bitdancer
Files	ripmq.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2012-04-03.13:41:44.540>
created_at = <Date 2012-04-01.15:33:50.891>
labels = ['docs']
title = 'Rip out mq instructions'
updated_at = <Date 2012-04-30.19:10:42.601>
user = 'https://github.com/pitrou'

bugs.python.org fields:

activity = <Date 2012-04-30.19:10:42.601>
actor = 'francismb'
assignee = 'none'
closed = True
closed_date = <Date 2012-04-03.13:41:44.540>
closer = 'pitrou'
components = ['Devguide']
creation = <Date 2012-04-01.15:33:50.891>
creator = 'pitrou'
dependencies = []
files = ['25102']
hgrepos = []
issue_num = 14466
keywords = ['patch']
message_count = 15.0
messages = ['157302', '157307', '157308', '157327', '157341', '157381', '157382', '157383', '157384', '157391', '157402', '157406', '157415', '157416', '159727']
nosy_count = 8.0
nosy_names = ['orsenthil', 'pitrou', 'ned.deily', 'ezio.melotti', 'eric.araujo', 'r.david.murray', 'python-dev', 'francismb']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue14466'
versions = []

[pitrou]

The devguide describes a mq-based approach (*) for generating patches, but it seems nobody (almost) uses it. We should therefore replace that description with a more traditional one ("hg diff").

(*) http://docs.python.org/devguide/patch.html#tool-usage

[merwok]

Yes please. We already have text if we look at the history before 73e11f64a704; we only need to agree on recommending “uncommitted changes in a clone” (which is okay to share patches but not for not ideal for more than one person working on something), named branches (what was in the previous text, because it makes it easy to run hg diff -r default and such commands) or bookmarks (lightweight named branches that some people recommend; I’m not sure how they’re better, given that in the end we generate a patch and make a new commit).

I, for one, use both uncommitted-changes and named branches; the former is easiest, but the latter safer: if I screw up a merge in a clone where I use a named branch, I can revert and retry the merge, but if I screw up merging pulled changes with my uncommitted edits, I risk losing them.

[pitrou]

I, for one, use both uncommitted-changes and named branches; the
former is easiest, but the latter safer: if I screw up a merge in a
clone where I use a named branch, I can revert and retry the merge,
but if I screw up merging pulled changes with my uncommitted edits, I
risk losing them.

I think uncommitted changes is fine for a simple introduction.
hg experts can use whatever they want without needing our help.

[ned-deily]

No one uses it? I'm surprised. I do and it seems to me by far the easiest and safest way to maintain patches in progress when there is constant churn.

[ezio-melotti]

+1
Most of the time "hg diff > bpo-12345.diff" is all that it's needed to produce a patch, and whenever I point someone to the devguide they usually get confused because they think they have to use mq.

FWIW I mostly use uncommitted changes, possibly on more clones, and since I usually upload the patch to the tracker I don't risk losing it in case I do something wrong.

[pitrou]

No one uses it? I'm surprised. I do and it seems to me by far the
easiest and safest way to maintain patches in progress when there is
constant churn.

Ah, good to know :) My wording was a bit too strong then.
However, I rarely see mq-produced patches when processing patches from contributors.

[bitdancer]

One person that I helped at the PyCon sprints was using it, because the devguide said to. But I think she was more confused by it than she would have been by 'hg diff', at least to start out. Or maybe not...but I wasn't able to help her with the mq commands, because I don't use mq myself.

I should try it sometime, I suppose.

[pitrou]

One person that I helped at the PyCon sprints was using it, because
the devguide said to. But I think she was more confused by it than
she would have been by 'hg diff', at least to start out. Or maybe
not...but I wasn't able to help her with the mq commands, because I
don't use mq myself.

mq is "advanced" compared to other workflows. It's a rather powerful and
sophisticated tool. I think people familiar with hg will have no problem
using mq even if we don't mention it. hg beginners, on the other hand,
will be more comfortable with something simpler.

[pitrou]

Here is a patch.

[bitdancer]

LGTM.

[ezio-melotti]

+ hg import --no-commit < mywork.patch

Is the '<' correct here?

I would also mention hg diff right away, and explain about adding/removing files after that.
The rest looks good.

[orsenthil]

On Tue, Apr 03, 2012 at 08:37:35AM +0000, Ezio Melotti wrote:

Ezio Melotti <ezio.melotti@gmail.com> added the comment:

• hg import --no-commit < mywork.patch

Is the '<' correct here?

No!. It should just be hg import --no-commit mywork.patch.

I asked around at PyCon to see if there were people using 'mq' just to
know about their workflow and it's advantages. I think only Ned
mentioned that he was using it, but everyone "theoretically" agreed
that it could be useful extension while working on a patch. When it is
not being used by many, I think it is just adding to the confusion by
it's mention in the devguide. +1 to remove it.

[python-dev]

New changeset e1d4b6dc9702 by Antoine Pitrou in branch 'default':
Issue bpo-14466: remove mq-based workflow
http://hg.python.org/devguide/rev/e1d4b6dc9702

[pitrou]

Done, thank you.