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.
> 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.
Most of the time "hg diff > issue12345.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.
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.
> 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.
On Tue, Apr 03, 2012 at 08:37:35AM +0000, Ezio Melotti wrote:
> Ezio Melotti <[hidden email]> 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.