When you accidentally press o for open/close in termui, it seems that there's no way to undo that without resetting the entire changes to an issue (e.g. new comments). (If there is, maybe it could be made a bit clearer in the UI?)

That can lead to repeated open/closes, like here: https://github.com/nh2/hatrace/issues/61#issuecomment-612296129

It would be nice to be able to undo those, or collapse operations that undo each other.

Michael Muré (MichaelMure) changed the title from Open/close operations are too easy to do and lead to dupplicate to Open/close operations are too easy to do and lead to dupplicate 5 years ago

Yeah, that could be done better indeed. Not sure what's the best solution though, it might be just an UX issue. Here is what I see as possible fix:

• Finish the transaction concept (https://github.com/MichaelMure/git-bug/issues/337) and give more control to UIs over what is pending and allow to revert
• Have the status change be "less easy":
  • have a "confirm" step ?
  • as the status will eventually have more values than open/closed, have a secondary UI to select the value
• have a way to "undo", but that implies knowing what can be undo as you must not remove operation that were already propagated. This could be limited to the pending ops. There is also a more general notion here of editing the pending operation (especially comments).

Michael Muré (MichaelMure) added label enhancement 5 years ago

Michael Muré (MichaelMure) added label area/ui/terminal 5 years ago

Michael Muré (MichaelMure) added label area/ui/web 5 years ago

Have the status change be "less easy":

I don't think that would help much, eventually people will get into the situation where they want to undo.

Another alternative:

One can already select messages and status changes by pressing ↓↑. Could the Del key simply remove the selected status change from the history?

E.g. pressing Del here could delete it:

If it is illegal to have multiple subsequent status changes to the same status, they could simply be collapsed into the first one.

From a UX perspective:

• when existing on other bug-trackers, editing the history appears in the form of editing/deleting/masking elements. Currently, git-bug only support editing a comment with a special Operation. It's possible to extend that system ("delete comment" seems to be the more probable) but it doesn't seems to be important to me, even to support importing from external bug tracker.
• having a way to edit the pending history is a different thing and would be helpful to give more control to the user. I'm noting this this sort of staging area for bug edition doesn't exist anywhere else. Not sure if that's a plus or a minus.
• there is two different concepts here: "undo" and "delete". It seems to me that it should be one or the other, not both to not overwhelm the UI/UX.
• "undo" is easy to understand and implement but can't alter something deep in the stack without being destructive
• "delete" doesn't have that limitation but also imply a trickier implementation because you can't delete everything: what happen if you delete the creation of a comment when there is a comment edition later ? In the future we will likely have more dependency like this.

From a technical perspective:

• unless it's "making the status change slightly more difficult", all of those solutions imply deeper control over those pending operation, possibly the notion of transaction as well. That would probably be a good thing to have but it's also quite a big piece of work and won't happen quickly.

Just ran into this when I pressed the 'o' key out of curiosity.

As a short-term workaround (to avoid issues with committed transactions and such), I think a simple "Are you sure?" confirmation dialog would be a good way to prevent fat-finger issues like I just encountered.

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

sudoforge removed label enhancement 1 year ago

sudoforge removed label area/ui/web 1 year ago

sudoforge removed label area/ui/terminal 1 year ago

sudoforge removed label lifecycle/stale 1 year ago

sudoforge added label area/bugs 1 year ago

sudoforge added label kind/feature 1 year ago

sudoforge added label priority/awaiting-more-evidence 1 year ago

sudoforge added label triage/needs-information 1 year ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/stale 1 year ago

Not stale

On Sun, Nov 3, 2024, 4:28 AM github-actions[bot] @.***> wrote:

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

---

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

— Reply to this email directly, view it on GitHub https://github.com/git-bug/git-bug/issues/367#issuecomment-2453278859, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACH6DPIRL6HOVWMWFRSWKTZ6WJ53AVCNFSM6AAAAABLJPUGZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGI3TQOBVHE . You are receiving this because you commented.Message ID: @.***>

github-actions (github-actions) removed label lifecycle/idle 7 months ago