From: Stefan Sperling Subject: Re: got backout/cherrypick auto commit To: Mark Jamsek Cc: Game of Trees Date: Fri, 20 Jan 2023 08:57:37 +0100 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.