Mercurial, consistent merges, and submission convenience

[John Goerzen]

On 2007-02-25, Thomas Arendsen Hein <thomas at intevation.de> wrote:
> * John Goerzen <jgoerzen at complete.org> [20070224 18:18]:
>>    From reading the docs, it appears that an "hg export" from one
>>    repo, then an "hg import" in another, is *not* the same as 
>>    pushing a changeset from one repo to the other, right?  That is,
>>    copies, renames, permission changes, patch hash, patch parents,
>>    etc. will not be preserved.
>
> Usually not, but you can make it this way:

Hi Thomas,

Thanks for the reply.

> - The patch header contains the parent node, but you have to update
>   to this node manually.

What happens if I don't?  Perhaps because the submitter's repo isn't
public anywhere?  Will the submitter have trouble pulling from me in the
future?

> - "hg export --git" preserves copy/move/executable and even binariy
>   content by using the extended git patch format.

Does it preserve the parent node ID as well?

Could the email extension be set to use this mode by default?  It seems
much more useful.

>>    Why, then, does hg email use hg export instead of hg bundle?
>
> Because you can't expect the whole world to use Mercurial. Plain
> (non-git) patches are accepted by almost any project.

Ah, I see.  A different paradigm.  Mercurial assumes that upstream isn't
using Mercurial, and Darcs assumes it is.  Actually, darcs has no direct
equivolent of hg email (though "darcs diff" is pretty close to hg
export).

> Maybe a config/cmdline option to send bundles via email would be
> what you want.

Yes, that would be ideal.

>> 2) An equivolent to "darcs send".
>> 
>>    Finally, if the remote repo has specified an email address for the
>>    maintainer, darcs can automatically look up the email address to send
>>    the bundle to, and sent it away.
>
> Mercurial doesn't have this "maintainer email address" field.

But perhaps it could be added to a well-known location, as with hg tag
--local?

>>    Thus, it's incredibly easy for a new person to download source,
>>    commit, and send me a set of darcs changesets:
>> 
>>    darcs get http://wherever.org/blahblah
>>    hack and darcs record
>>    darcs send
>
> Hmm, might be really nice. Shouldn't be very hard to do as an
> extension where a .hgsomething file in the repo contains the
> maintainer address and maybe if this maintainer prefers bundles or
> patches.

> But I don't know how suitable this would be for general use, imagine
> people cloning the main hg repo, doing some work on it and publish
> it on their web server. Now I clone this secondary repo (which still

The key is to make the file not come across with cloning.  That is, it's
not part of the versioned data of the repo, but part of the metadata
about that repo.  I'd think that something along the lines of "hg tag
--local", where it stores the local tags in .hg/localtags, would be in
order.  If you have, say, .hg/email, looking something like:

address=foo at example.com
bundles=true

This should be trivial for the Mercurial client to download from a
public repo at the time of an "hg send".  Mercurial will have to go out
over the network at "hg send" time anyway to determine what changesets
need to be sent.

This would also let the repo submission address change upstream when
necessary.

Darcs works this way and it seems to work well.

>>    hg clone http://wherever.org/blahblah
>>    hack and hg commit
>>    hg bundle /tmp/foo http://wherever.org/blahblah
>>    ( look up the email address for the maintainer at wherever.org )
>>    ( compose an email to that maintainer, attaching /tmp/foo to it )
>
> Of course these are some additional steps. The benefit is that there
> is less magic behind them. Behaving non-magical is one of the main
> benefits of Mercurial's core (and my main problem with darcs).

I can certainly see that tradeoff wrt darcs' patch algebra (which has
some known cases where it fails spectacularly, and that is the reason
I'm looking at hg).  

I'm not suggesting that some existing command be changed.

But if this is an extension, it is just another barrier to Joe Random
Hacker being able to quickly pick up my tree, hack, keep up-to-date,
etc.

I want a programmer that has no prior experience with my VCS of choice
to be able to trivially install the VCS, check out my tree, hack, and
send me patches.  The easier I make it on the public, the more patches I
receive.

I link to my "5-Minute Guide to Contributing With Darcs" from my project
websites.  It's at http://software.complete.org/site/wiki/DarcsGuide

Mercurial looks to be as easy as Darcs everywhere except step 5
(submission), which prompted my comment here about darcs send.

If I have to tell people how to download and install an extension
(across various different OSs at that), edit their .hgrc to enable it,
and *then* finally they can submit...  well, that's not as easy for
them.

I don't think that this is all that terrible of "magic" anyway -- you
just find the submission address from a well-documented source location,
figure out what you have that they don't, and send it.

>>    2) hg qpop removes changesets.
>> 
>>    This seems boggling.
>
> qpop is part if mq, which is an extension which violates the
> append-only paradigm of Mercurial.

I think it would be very good to document this prominently on the wiki.
As I don't really even use hg yet, perhaps someone that actually knows
what's going on could do that.  But I'm willing to give it a shot.

>>    repo, I guess I would have to push two different things in order
>>    to push my local tree of hacks to the remote?
>
> You should not allow direct access to your working repo with mq
> patches applied, but you can push it to a temporary location with a
> warning sign: "Be prepared that hashes change"

That also should be prominently displayed on the wiki.  With that
restriction, what does mq actually offer that quilt doesn't?  If I lose
the ability to easily collaborate on my local branch, it seems I've lost
a lot.  I have that same complaint about git; its commands such as
rebase seem to work on the premise that there is only one repo for any
given project that others actually pull from.

> The second alternative is of course to publish your patch queue
> (.hg/patches) directly.

Yes, I will have to think this one through.  I haven't fully grasped how
that would work yet.

>>    How also does all of this differ from the TransplantExtension,
>>    which seems to do the same thing?
>
> With mq you have the qrefresh command to change patches until you
> and/or upstream like them. With transplant you can cherrypick or
> rebase existing patches but not modify patches.

Hrm, maybe I'm being dense, but what is the difference between rebasing
and modifying?  I would have thought that rebasing could, in fact,
modify (to fix merge conflicts, etc.)

Does TransplantExtension use have the same potential drawbacks on
collaboration with others as mq does?  Again, I'm guessing yes;
git-rebase certainly has that drawback.

> You could backout your cherrypicked 10 and then pull+merge as usual.
>
> Or use the TransplantExtension which is designed to do cherry
> picking. It adds a mark to transplanted changesets (visible with
> 'hg log --debug' in the transplant_source extra field).

Interesting.  I re-read the TransplantExtension page on the wiki, as
well as its help information.  I am confused about how its merging
relates to regular hg merge; transplant has a --merge, hg has a merge,
and it's not clear to me exactly the difference between various hg
transplant --all commands and a normal hg fetch.

Thanks again for the insight.

-- John