Issue #1727 resolved

Option in merge dialog at commit stage for subrepos recursive commit

Dmitry Zanozin
created an issue

Since mercurial introduced --subrepos flag we need an additional option in merge dialog to set it.

It's very confusing now to see abort message after resolving all conflicts in subrepos.

Comments (19)

  1. Dmitry Zanozin reporter

    Trying again: We need a method to call the following command:

    hg ci --subrepos -m"message"
    

    particularly at the last stage of merge dialog when we are ready to commit.

    It's impossible now to merge and commit with THG at the same time if you use subrepos.

  2. Andreas Kaempf

    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.

  3. Angel Ezquerra

    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.

  4. Dmitry Zanozin reporter

    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.

    In this workflow we need this checkbox.

  5. Dmitry Zanozin reporter

    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.

    I'm sure you'll make the optimal choice.

  6. Angel Ezquerra

    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.

  7. Dmitry Zanozin reporter

    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.

  8. Angel Ezquerra

    I think you are right even if I have my reservations about this workflow as I said above...

    One solution could be to add a warning dialog when you hit commit or enable the checkbox...

    I'll think about it...

  9. Dmitry Zanozin reporter

    BTW (another remark on merge dialog): current merge dialog's design force user to commit after merge.

    We have 2 buttons: Commit | Cancel

    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.

  10. Angel Ezquerra

    Hi guys,

    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.

  11. Steve Borho

    merge: rename Commit and Cancel buttons on "commit page" of wizard (refs #1727)

    This clarifies the fact that closing the wizard or clicking the old "Cancel" button on the Commit page of the merge wizard does not really cancel the merge. It just avoids the final commit.

    This issue was brought up while discussing issue #1727.

    → <<cset 61a7eccb5649>>

  12. Dmitry Zanozin reporter

    (Reply via dmit...@mail.ru):

    Hi, Angel!

    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?

    Dmitry

    16.11.2012 11:51, Angel Ezquerra wrote:

  13. Steve Borho

    merge: let the user change the commit options on the merge wizard commit page (fixes #1727)

    An "options" button has been added to the "commit panel". This button opens the same "Options dialog" that is shown when you click the "Options" button on the commit widget.

    If some commit option is set, it will be shown on the commit panel as well, and the options will be taken into account when making the commit.

    → <<cset 35febb954904>>

  14. Log in to comment