Thoughts on multi-step commands

[Matt Mackall]

On Wed, 2013-07-03 at 15:25 -0700, Siddharth Agarwal wrote:
> On 07/03/2013 12:34 PM, Matt Mackall wrote:
> > 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
> 
> 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.

Can I add files in this state? If so, what does wlock mean? If I can't
add files.. what if I wanted to add files?

-- 
Mathematics is the supreme nostalgia of our time.