Yes.

This is solved by the new merge/resolve machinery, isn't it?

Exactly... when you have a thousand people and tens of 'main' repos, that gets
fun quickly.

Same as hgeditor, you can enable it in ~/.hgrc

Except that each repo child has to set that by hand, right? Or is there someway
to set an hgrc on a clone?

no hgeditor isn't call with commit -m foo. on the other hand, a precommit hook
will work better.

What is hgeditor? Does it cover hg commit -m 'foo' ?

I have yet to hear why adding three lines to hgeditor to find conflict markers
isn't sufficient. Nor am I clear on what "resolved" does.

Thomas, sure if the dirstate can retain that info, that would be even better.
The essential thing would be to have a workflow supporting "hg merge", "hg status"
and "hg resolved".

movement: see
http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/6655/focus=6687

What's the reasoning against looking for conflict markers? That they may be
arbitrary text?

cboos, I haven't thought about whether your solution is good or bad, but this  
shouldn't be done with a separate file. We have the dirstate for such things.

As discussed recently on the mercurial list, Matt made it clear
that looking for merge/conflict markers was wrong.

Therefore I reiterate my alternative proposal:

In addition to just mentioning a merge failure when the merge 
script failed, hg merge should leave a file behind as a conflict
marker (that could be an empty file having the same filename,
with a ".conflict" suffix added).

The advantages of doing that at the Mercurial level instead of
doing this at the hgmerge script level are multiple:
 - custom hgmerge tool won't have to care about that, and 
   possibly forget to do it or do it wrong; therefore, the
   new mechanism will support already existing custom merge 
   tools,
 - "hg status" could check about those "xxx.conflict" files
   and appropriately flag those files as: C = conflicted.
 - "hg commit" could check about those "xxx.conflict" files
   and refuse to proceed, in case they're left around.
 - we'd need a "hg resolved" command which would remove 
   those conflict marker files; quite similar to the SVN situation.

Reopening this issue to discuss not allow committing a file with conflict
markers if working directory has two parents.

There is already a discussion about this in issue12.

Mercurial lets a commit succeed if a merge fails.  Here's what I mean:

    $ hg init a
    $ echo a > a/a
    $ hg --cwd a commit -Am a
    adding a
    $ hg clone a b
    $ echo b > a/a
    $ hg --cwd a commit -m b
    $ echo c > b/a
    $ hg --cwd b commit -m c
    $ hg --cwd a pull ../b
    added 1 changesets with 1 changes to 1 files (+1 heads)
    $ HGMERGE=merge --cwd a up -m
    merging a
    merge: warning: conflicts during merge
    merging a failed!

This leaves unmerged files with commit markers littering their internals.

It's pretty easy to do this by mistake.

By default, commit should abort if the dirstate has two parents and any files
contain merge markers.  This could be overridden with -f.

An alternative would be to provide a precommit hook in contrib, but I'd prefer
the default behaviour to change instead, as it's not nice to make it easy for
users to shoot themselves in the foot.