On Fri, Jan 20, 2023 at 04:45:47PM +1100, Mark Jamsek wrote:
> If the user has cherrypicked or backed out some commits and then decides
> not to commit, a `got revert` is likely; would it be good to clear the
> reverted cherrypick and/or backout references upon `got revert`?
> Otherwise, if the user fails to run `got {backout,cherrypick} -X`, the
> stale log messages at the next `got commit` could be confusing.

Indeed, 'got revert' is a possible action instead of 'got commit'.

In general it is difficult to detect what is being reverted exactly.
But we could try to come up with heuristics. I suppose in case all
files touched by a particular cherrypicked commit are fully reverted
then 'got revert' could remove the corresponding cherrypick reference.
This would at least cover the 'got revert -R' ("throw it all away")
use case, but leaves a log message template in place if there are
unrelated changes in a file made by other cherrypicked commits.

Beyond just comparing changed-paths we could try to compare diffs.
But that might not be 100% foolproof because some changes have more
than one valid presentation.

Supporting the 1:N commit:cherrypick model makes this difficult,
Whereas supporting just 1:1 would make it easier.
But I don't know how we could force the user to run 'got commit'
immediately (apart from adding your -a flag of cource), without
making the use case of cherry-picking multiple changes into a
work tree more complicated to use than it is now.

I'll try to think a bit more about this.