in main now

Pushed update-more-verbose.patch to crew
(with small modifications to revert/backout, so they don't display the stats)

Still TODO:
don't allow commit of files with commit markers unless --force is used

I'll reopen issue122 for this and transfer nosy list.

tonfa suggested I add a comment here.

Often, I don't want to resolve merges immediately after a pull. Rather, I want
the files left with merge markers, so I can come back to them individually later.

Unfortunately, if I forget some of these, hg lets me commit those files with the
markers still in place, unlike (some?) other SCMs. It should be checking for
this and not letting me commit until I've resolved the merges.

On Tue, 2006-05-02 at 08:07 +0000, Benoit Boissinot wrote:

> It looks good for me, maybe Brian wants to comment ?

+1

	<b

On 5/2/06, Thomas Arendsen Hein <mercurial-bugs@selenic.com> wrote:
>
> Thomas Arendsen Hein <thomas@intevation.de> added the comment:
>
> *ping*
> should I apply update-more-verbose.patch?
>

It looks good for me, maybe Brian wants to comment ?

Benoit

*ping*
should I apply update-more-verbose.patch?

Attached is a patch proposal for 1. and 2a.
(Tests are not adapted yet)

On Tue, 2006-04-04 at 08:30 +0000, Thomas Arendsen Hein wrote:

> Maybe a different message should be shown instead of "branch merge, don't forget
> to commit" if there are unresolved merges?

+1

> 1. Tell the user that this is a problem which probably needs to be solved before
> committing.

+1

> 2a. Tell the user how to redo all merges (e.g. hg co -C one && hg merge two)
> and/or

+1

> 2b. Tell the user how to fix the failed merges, this needs a way to tell the
>  user which merges failed, not only how many failed. One solution for this would
> be what msg473 suggests. This would abort with "conflict detected in file
> foo/bar" or something like that.

This would be the best thing to do.  It sucks to have to redo an entire
merge because one file fails; I've had to do this a number of times with
other SCM tools.

In fact, sometimes I find myself with say 6 files to merge, I get
through the first 4, then I find that I want to redo my merge of file 2
because I've forgotten something.  If we had a way of redoing a merge of
one file, it would presumably handle this case, too, which would make me
very happy.

	<b

The output with -v is somewhat better, e.g.:
 0 files updated, 4 files merged, 0 files removed, 1 files unresolved
 (branch merge, don't forget to commit)

Maybe a different message should be shown instead of "branch merge, don't forget
to commit" if there are unresolved merges?
1. Tell the user that this is a problem which probably needs to be solved before
committing.

2a. Tell the user how to redo all merges (e.g. hg co -C one && hg merge two)
and/or
2b. Tell the user how to fix the failed merges, this needs a way to tell the
 user which merges failed, not only how many failed. One solution for this would
be what msg473 suggests. This would abort with "conflict detected in file
foo/bar" or something like that.

If you use -v you have a summary of the files merged, unresolved, etc. Should it
be more verbose by default ?

What is the status of the suggestion in the msg473 ?

regards

msg470 in issue122 makes another suggestion:
Don't allow commit if the repo has two parents and there are merge conflict
markers in any commited file, unless -f is used.

The returned error code is good. Further enhancements may be:
- Aborting on the first failed merge _or_ showing a summary of failed merges at
the end.
  (My first guess is that the first one is better)
- getting into a consistent state or tell the user how to get that.

in tip

thomas, is the attached patch what you would like ?

When hgmerge returns with an error code, Mercurial simply ignores this fact.

What you can do is:
hg co -C `hg parents -q|head -n 1|cut -d: -f1` && hg co -m

But it would be good to know about the problem.
(there are "merging foo failed!" messages, but with the following call to
hgmerge this might not be visible on the screen anymore)

The biggest problem here is that the second parent gets added before any merging
happens. Thus if a merge aborts part-way through, it gets marked as "done".

So I've made it last. Now, if merge breaks, you end up with your merged files,
your .orig files, and you can simply restart the merge. Any files that were
manually merged earlier should automerge on the second attempt.

I just copied it out of the ToDo list. I think if $HGMERGE returns false, the
merge falls over and there's no good way to restart it.

Could you expand a little on what you mean by this?