[RFC] New core command: graft
mpm at selenic.com
Mon Oct 10 13:42:56 CDT 2011
On Mon, 2011-10-10 at 20:10 +0200, Antoine Pitrou wrote:
> 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.
Yes, we track/display two parents for the working directory rather than
> > 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.
This was already in my example, so the real question is "how do we find
out we're in the middle of a graft AFTER that?"
> > How do we get out of this state?
> I suppose you could get out (aka cancel) using "hg rev -a" or "hg up -C".
Ok, so far this approach has infected at least commit, revert, update,
merge, summary.. probably everything that touches the working directory
will need to know about it.
> > 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?
No. That's the normal mode. And that hardly matters: it already exists.
The questions is how do we add this new feature without rewriting
everything. We don't want to add new logic to just about every other
command and extension so that it now interacts properly with a graft,
which is where this snowball of yours is going.
The graft command has to be self-contained to be viable, so requiring
hooks in commit is out.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel