Issue #1044 resolved

Update to wrong patch when double-clicking patch revision in workbench

Colin Caughie
created an issue

If I have patches A, B and C applied, and I double-click B in the workbench, I expect this to behave like "qgoto B" and leave me with A and B applied.

What actually happens is that both C and B are qpopped, and I'm left with only A.

There appears to be no way to do a "qgoto B", since if I double-click C I get a diff view of the patch, not a qpop operation.

Comments (8)

  1. Angel Ezquerra

    This is something that I had never tested myself. I always assumed that people would use the context menu to apply/unapply patches.

    In fact I would have expected double clicking on an applied patch would behave as if it were a regular patch. That is, I would have expected to get the revision diff (as for a regular revision). I think that it is a bit weird and certainly inconsistent that double clicking on the topmost patch shows its diff, but double clicking on any other applied patch performs an mq operation.

  2. Alexander Grebenschikov

    If I have patches A, B and C applied, and I double-click B in the workbench, I expect this to behave like "qgoto B" and leave me with A and B applied.

    This behaviour was until v2.0.5.

    What actually happens is that both C and B are qpopped, and I'm left with only A.

    This behaviour was started from v2.1.1.

    I like how it works in v2.0.5. Is it possible to restore behaviour from v2.0.5?

    When I double click on patch then it poping including this patch (v2.1.1 - 2.1.2). In v2.0.5 it poping until clicked patch, but clicked patch does not poping. It is change in UI behaviour or it is a bug?

  3. Angel Ezquerra

    The current behavior is intentional. It makes double clicking on an applied patch perform the same action as the "Modify history/Unapply patch" menu.

    I am not against changing the behavior. I see why people may expect double clicking to make the selected patch the topmost patch, as long as we are fine with having a different behavior than the " Modify/Unapply patch" menu.

  4. Anonymous

    From my point of view this would be the right thing to do. By integrating the patch queue with the regular revision history (which I think is a great feature), you raise the expectation that actions on MQ patches will behave at least somewhat similarly to actions on regular revisions.

    Double-clicking on a regular revision updates the work area to that revision, popping any applied patches. To be consistent with this, double-clicking a patch, whether it's applied or unapplied, should update the work area to that patch, applying it and any of its predecessors and unapplying any later patches as necessary.

    Tying the double-click behaviour to some context menu item two levels deep just doesn't make sense IMO. One thing that might make sense though is to replace the "Update..." item at the top of the context menu with "QGoto" when the selected item is a patch and not a regular revision. This way the double-click behaviour would match the first context menu item.

  5. Angel Ezquerra

    I don't think that we should replace the "Update..." item as you suggest. I think it would confuse most users users.

    On the other thand, I agree with the rest of your post. I'll see what I can do about it.

  6. Steve Borho

    repowidget: Make double clicking an applied patch qgoto that patch (closes #1044)

    The original behaviour was unapplying the double clicked patch (qgoto its parent). This was the same behavior as the "Modify history/Unapply patch (QGoto parent)" command on the context menu.

    Note that the context menu command remains unchanged. This is desirable because it makes it easy to unapply the lowest patch, without having to look for its qparent.

    0586fbfe6e80

  7. Log in to comment