Best-guess drop of commits

[epage]

Unlike in #3, not all commits drop cleanly

• if you had a branch get squashed when pulled into upstream. It'd be nice if we could guess based on the summary.
• Possible rebase conflict resolution?

If we identify a best-guess at the start of a branch, we should then proceed to delete the whole branch, assuming they were all squashed.

This should be configurable.

[arxanas]

The way git-branchless solves this is via two mechanisms:

• Drop commits with the same patch ID. This handles the case of commits being applied out of order upstream.
• Drop commits which are now empty after the rebase. This mostly handles the case of squashed commits.

See https://github.com/arxanas/git-branchless/blob/6d76356a6bca1f040a1b7665d4549a2bd06ea6ce/src/core/rewrite/plan.rs#L65-L71.

If a branch points to a commit which has been skipped as a result of one of the above two, then it's deleted.

In practice, this solution has worked fairly well for me, although it's indeed not ideal for the case of squashed commits.

[epage]

Drop commits which are now empty after the rebase. This mostly handles the case of squashed commits.

I recently handled this with tree-id, see epage@a472ed6

Drop commits with the same patch ID. This handles the case of commits being applied out of order upstream.

This was the next idea I was going to play with but glad you brought it up because I kept not finding this idea, so its good we are spreading it around.

[epage]

I'm assuming the optimization at arxanas/git-branchless@16b0c69 mentioned at libgit2/libgit2#6036 is helpful for generating the patch ids.

[arxanas]

Furthermore, we're careful only to calculate patch IDs for commits which have touched exactly the same paths, as diff calculation is still slower than calculating the paths changed in a given commit. We also do it in parallel, which is important for large repositories. See https://github.com/arxanas/git-branchless/blob/331b7cf2a37d00a3d54ba5df00f3d702aa7b3948/src/core/rewrite/plan.rs#L700-L710