Don't offer Retry when a merge has conflicts

[Ian Clatworthy]

The recently added Retry button when a command fails is nice. The only problem is that it gets displayed unexpected now and then, e.g. when a merge has conflicts. In this case, I don't expect to see Retry because there doesn't seem any reason to try running the command again. If that's the case, I think the dialog should just offer Close.

[Craig Hewetson (craighewetson-deactivatedaccount)]

It would be great if the retry button can be replaced with:

"merge conflicts..." when conflicts happen on merge and update dialogs;

"update" when committing on a bound branch when the server and client revisions differ; (NB: for me :) )

"commit changes..." when trying to merge when there are uncommitted changes in the local branch.

This would make it easier for the user, since he/she would not have to close the dialog kick off another dialog then open it again. I run into this alot with bound branches commit and update etc. This usually gets my colleges swearing under their breath :)

I know this might introduce alot of complexity but I think it would greatly improve the user experience.

[Jelmer Vernooij (jelmer)]

On Mon, 2010-03-01 at 10:47 +0000, Ian Clatworthy wrote:
> The recently added Retry button when a command fails is nice. The only
> problem is that it gets displayed unexpected now and then, e.g. when a
> merge has conflicts. In this case, I don't expect to see Retry because
> there doesn't seem any reason to try running the command again. If
> that's the case, I think the dialog should just offer Close.
Perhaps it could offer a way to invoke "bzr remerge" with a different
merge algorithm.

Cheers,

Jelmer

[Ian Clatworthy (ian-clatworthy)]

Same issue is affecting qdiff. See bug #520939.

[Gary van der Merwe (garyvdm)]

This is partial fixed. The retry now correctly shows only when there is an error.

I am going to keep this bug open for the feature request to show the option to show the option to open the conflicts window, or to remerge. I can't use the same method that the other info widgets, like when the branch is out of date, or the when the working tree contains uncommitted changes, use. This requires a command to raise an error, which correctly does not happen when there are conflicts. In order to detect conflicts, we need to look for a return code of 1. But for diff (and may be others), a return code of on means something else, so this needs to be command specific, but should probable exclude diff, rather than include, as the number of commands that do merges is numerious, e.g. update, pull (with wt), rebase, etc...