I can only emphasize the importance of this. Hg and subrepos are quite difficult for my colleagues to master, flaws like this dramatically diminish the acceptance!
It cannot be that a big deal to add the options from the commit dialog of the current repository.

Sorry I did not reply to this before. I must have missed the assignment notification.

If I understand this correctly, what you'd like is to add a checkbox to the last panel of the merge dialog that would let you force a commit of all dirty subrepos?

Personally (as a heavy subrepo user) I do not think this is a very good workflow. When you use the --subrepo flag mercurial will use your top level commit message for all subrepo commits, which is not often what you want. That is in fact the may reason why mercurial requires you to add a flag when you commit and by default will not commit dirty subrepos.

That being said, if mercurial provides that flag I guess we should provide it too, although I think it should be disabled by default.

Yes. It would be great to have a checkbox on the last panel of the dialog.

I'm totally agree, that this chechbox should be off by default.

In our workflow we have default and stable branches in main and in a number of subrepos which are perfectly synchronized. All changesets in stable branch of main repo linked with stable changesets in subrepos. The same with default branch. Usually we have "Merge with stable" operation which is actual and valid for all related (sub)repos.

On the other hand we already have the same checkbox in commit options. Do you think we need different options for recursive commit or just use existing option's value on the last stage of merge dialog?

This option can be saved into repo hgrc file already. May be this is the right way to minimize number of settings.

In fact you can already use the existing option _today_ by not using the commit button on the merge dialog and instead committing from the workbench window itself.

This is arguably a much saner workflow. When you merge you (potentially) let mercurial automatically modify your files. You should check that the merge is correct _before_ actually committing your changes. I believe that is the reason why merge is a two step process in mercurial, i.e. first run hg merge, _then_ run hg commit, hopefully after having tested your changes. This is even more important when working with subrepos, where it is much easier to screw up the merge.

I personally never use the commit button on the merge wizard, and I always advice my colleagues to do the same.

Since I think this is not a very good workflow, I'm not sure this is something we should encourage by adding an option to the merge dialog even if it should probably be there for consistency's sake. I'm a bit torn on this, to tell you the truth.

I understand your position but in my mind if we have commit stage in merge dialog it should have the same functionality as common commit dialog (at least for subrepos flag because merge itself change the state of subrepos).

I can't find any reason (to explain to someone else) why we can merge_commit without subrepos but can't merge_commit with subrepos when separated merge + commit being processed successfully.

If we want to force everyone to check results of merge operation before commit we should completely remove commit stage from the merge dialog. But as far as we keep this feature (instant commit after merge) we shouldn't limit it functionality.

In your workflow skipping commit stage we need to press Cancel (the first thought that it cancels whole merge procedure). After that additional conformation dialog appears with warning about necessity of commit and again with "strange" buttons "Exit | Cancel". Here Cancel button returns us to commit stage of merge dialog.

To implement your workflow more user-friendly we need to rename Cancel button to "Finish/Continue without commit" or something like that. Сonfirmation dialog should have more suitable notification explaining that two different approaches/workflows (instant merge+commit or "merge + check + commit") can be applied by user choice and other button's names as well.

I have recently submitted a few patches that I believe address these issues:

I have renamed the Commit button to "Commit Now" and the Cancel button to "Commit Later"

I have improved the "Cancel" (i.e. Commit Later) dialog, indicating what must be done to really cancel the commit

I have added an "Options" button that lets you show the commit options dialog to control settings such as recurse subrepos, username, etc

The merge commit will now take into account your global and repository commit options (i.e. if you use the regular commit options dialog to set and save some options, the merge commit will use them).

I don't think all (or even any) of these will make it into the next release, since we are on a code freeze right now (unfortunately I had not time to work on this until now), but I hope they will make it into the following release.

Sounds good!
I've just seen the latest changesets at https://bitbucket.org/tortoisehg/thg
There are only renames of buttons and update of "cancel message".
No changes for commit options.
Does it mean that someone (Steve?) has "dropped" some of your patches and
they will not be included in the next releases?