Thoughts on multi-step commands

Matt Mackall mpm at
Wed Jul 3 14:34:48 CDT 2013

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:

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

- 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.


- 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.

More information about the Mercurial-devel mailing list