Thoughts on multi-step commands

[Matt Mackall]

On Wed, 2013-07-03 at 11:35 -0700, Siddharth Agarwal wrote:
> I wrote up some initial thoughts on properly dealing with multi-step 
> commands here: http://mercurial.selenic.com/wiki/MultiStepCommandPlan

http://mercurial.selenic.com/wiki/WikiStyleGuide

We probably need a new type of includey marker thing for pages that are
just proposals so that random visitors don't take everything as gospel.

> There's almost certainly some cases that I'm missing, so feedback would 
> be appreciated.

I'm rather skeptical about hooking into locking. AFAIK, we've got three
concerns:

- reporting when we're in the middle of a graft/rebase/whatever (done)
- blocking commits when we're in the middle of graft/rebase/whatever
- allowing commit inside the continuation of our particular whatever
- nuking graft/rebase/whatever state when we update away from it

The whatevers I'm aware of are (let's call 'em commit blockers):

- interrupted checkout (see below)
- graft
- rebase
- histedit
- evolve?

(but not bisect!)

I don't think we need to block all callers of commit, as many of them
(like rebase) check for a clean working dir before beginning. So it
might be as simple as adding a checkcommitblock()/clearcommitblock() API
that checks/nukes the registered state files and adding them in a small
handful of places.

Questions:

- should any old update nuke commit blockers? (yes?)
- should we prevent graft from running in the middle of a histedit, if
we somehow end up back at the shell with a clean working dir? (yes?)


Thoughts on interrupted checkout:

It now occurs to me that we can 'unify' this with the others. When
checkout starts, we create a state file that contains the target hash
and delete it on completion. Summary can look for it, much like it
reports graft and rebase now. And update --continue could simply
re-attempt the update. This might just do the right thing with merges
too, hard to say without more thought.

-- 
Mathematics is the supreme nostalgia of our time.