Continue/abort a conflicted cherry-pick or revert

[stefanhaller]

• PR Description

This is part one of a four part series of PRs that improve the cherry-pick and revert experience.

With this first PR we make it possible to continue or abort a cherry-pick or revert operation, in the same way you can continue or abort a rebase or merge. Currently this is only relevant for revert, because lazygit doesn't use git cherry-pick for copying/pasting commits. This will change in a later PR in this series though, so here we are already preparing for that.

Fixes #1807

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 89ba3f21	✅ 97.89%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (89ba3f2)	Report Missing	Report Missing	Report Missing
Head commit (90db796)	54579	47363	86.78%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#4441)	284	278	97.89%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[jesseduffield]

Nice work. One thing

[jesseduffield]

I don't like how we're using the same type (WorkingTreeState) for the bits as for the bitfield. Naively I would expect that I could directly check if workingTreeState == WORKING_TREE_STATE_CHERRY_PICKING but that's really only going to return true if we're only cherry picking and not also merging. I also can't do if workingTreeState == WORKING_TREE_STATE_CHERRY_PICKING || workingTreeState == WORKING_TREE_STATE_REBASING to ask if it's either cherry picking or rebasing.

So I'm wondering, how about we just have a struct of booleans:

type WorkingTreeState struct {
  rebasing bool
  merging bool
  cherryPicking bool
  reverting bool
}

And then define methods on that struct. We can still have the .Effective() method which returns the enum value.

[stefanhaller]

Good point. Yes, a struct is an improvement to this.

I couldn't do this as a fixup, so I rebased and force-pushed. I added dceb196 as a preparation, and then d2573dc is the changed commit. The rest of the branch is unchanged except for adaptions to the new API.

[jesseduffield]

LGTM