Thoughts on multi-step commands
sid0 at fb.com
Wed Jul 3 17:25:54 CDT 2013
On 07/03/2013 12:34 PM, Matt Mackall wrote:
> 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
To be clear, these should block each other and themselves as well. So
you shouldn't be able to start a rebase in the middle of an interrupted
histedit -- or an interrupted rebase, for that matter. That was my
original idea behind hooking into locking -- it seemed like anything
that holds the wlock and then gets interrupted shouldn't interfere with
anything else that wants the wlock. The wlock would then sort of extend
across process invocations, and only the operation that originally had
the wlock can take it again.
> - evolve?
Probably, if it's an interrupted evolve.
> (but not bisect!)
I'd consider commits or rebases in the middle of bisects to produce
strange, or at least unexpected, results. This can be a debate for a
future iteration, though -- committing in the middle of rebase is more
> 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?)
Maybe only with --clean? update --clean in the middle of a rebase
produces different results from rebase --abort, however.
> - 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?)
Yes, I'd think so.
> 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.
Yes -- with the wlock-across-process-invocations philosophy, an
interrupted update is just another interrupted operation where the wlock
hasn't really been given up yet.
More information about the Mercurial-devel