[Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers.

[Antoine Pitrou]

On Mon, 07 Feb 2011 14:34:35 +0000
Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> >>>
> >> And from the description it sounds like rdiff will be very useful for
> >> our usecase.
> > I'm not sure it is really. When you commit multiple changesets
> > locally you really want to use something like named branches or mq to
> > track them. Advocating rdiff is advocating something SVN-like, it's not
> > very helpful IMO.
> >
> 
> Although often you want to merge in a single commit and erase the commit 
> history of the branch you worked in (as discussed previously).

Yes, but apparently rdiff compares the *working copy* rather than the
local repository. Also, AFAIU rdiff will compare against the tip of the
remote, which is probably not what you based your work on. And if you
have to specify revisions by hand, it kind of defeats the point (you
want hg to track changes by itself, which is why you want to use one
of named branches / bookmarks / mq / etc.).

> So are 
> you advocating rebasing before merge as the alternative?

I'm not advocating anything in particular really. I think creating a
named branch "foo" (or a bookmark? I've never used them but it sounds
like they might do the trick) and then using "hg di -r py3k" to get the
diff against upstream is very reasonable. That's without any hg
extension activated.

Throwaway clones are good too, since they avoid the issues with
"rebasing" or "erasing commit history".

But if we suggest people use some extension, I'd rather see us advocate
mq (or shelve or any equivalent) rather than something low-level such
as rdiff.

Regards

Antoine.