[RFC] New core command: graft

[Antoine Pitrou]

On Mon, 10 Oct 2011 12:55:39 -0500
Matt Mackall <mpm at selenic.com> wrote:
> > > 
> > > Which gets us back to 'original author/date/description are now lost'.
> > 
> > They are not if you keep track of the grafted changeset id, and display
> > its id as part of repository-inspecting commands (such as hg log).
> > Since you can only graft changesets from the same repo there shouldn't
> > be any problem.
> 
> Ok.. so I type:
> 
> $ hg graft 15199
> grafting changeset 15199
> (don't forget to commit!)
> $ hg commit
> 
> Where is the author/date/description/graft-origin stored between these
> two commands? How does commit know to retrieve it? They're lost unless
> we add a lot of new logic -outside- of the graft command.

I would say you only need to store the grafted changeset id since they
rest can be derived from that. How do merges work? It seems they do
have to track some additional information as well.

> How do we indicate to the user that their working directory is currently
> in this new 'in the middle of a graft' state and their next commit will
> finish the graft?

Like for merges, something like:

$ hg graft 81380082d216
3 files updated, 0 files unrevolved, remember to commit.

> How do we get out of this state? 

I suppose you could get out (aka cancel) using "hg rev -a" or "hg up -C".

> Making commit 'modal' like this introduces a lot more problems than it
> solves.

Isn't commit already 'modal', since it will refuse to commit if you
have some merge conflicts left unresolved?

Regards

Antoine.