Hello Ian, I'm working my way through NOTES.git-debrebase-pseudomergehandling.
ISTM from your notes that the script will need four user subcommand: 1. strip pseudomerges and cleanup the branch, i.e., start or continue a debrebase 2. finish a debrebase by pseudo-merging the remote interchange branch This is what the `git debrebase prep-push` hook would do, but the user needs to be able to make it happen in order that they can publish a branch that fast-forwards from the result of `dgit clone`, without doing an upload. 3. start a `git rebase` onto a new upstream version 4. special command to protect pseudomerges that the user wants to keep Users normally think of rebases as operations that are first started, potentially interrupted by conflicts, and then finished. We are fine with (3), because this is just a wrapper around git-rebase(1) and users know how to deal with its --continue, --skip and --abort options. In the case of a debrebase, there will never be any conflicts to resolve, but until (2) has occurred, the result strikes the user as unfinished. The workflow was sold to them as producing something that is a ff of the interchange branch, but it isn't a ff of the interchange branch yet. They wonder "did I forget a --continue somewhere?" How about calling (2) immediately after (1) -- and if there is a clean way of doing it, after (3), too? That way, the user can conceptualise the debrebase operation as "make the history into a nice patch series, and use a bit of magic to ensure that this is still fast-forwarding". They don't have to try to understand the state before the final pseudomerge is back on top. -- Sean Whitton
signature.asc
Description: PGP signature
