[RFC] New core command: graft

[Matt Mackall]

On Sun, 2011-10-09 at 20:51 -0500, Augie Fackler wrote:
> On Oct 9, 2011, at 7:34 PM, Matt Mackall wrote:
> 
> > On Mon, 2011-10-10 at 00:52 +0200, Pierre-Yves David wrote:
> >> On 10 oct. 2011, at 00:23, Matt Mackall wrote:
> >> 
> >>> The implementation I have so far works, but there's still some work to
> >>> do:
> >>> 
> >>> - needs to actually support --continue
> >>> - needs testing
> >>> 
> >>> Among other things, I'm looking for feedback on the UI and what features
> >>> are critical. Right now, it copies the details of grafted changesets
> >>> (user/date/description) verbatim. That's an ok default, but it seems
> >>> like we'd like to be able to tweak that.
> >> 
> >> 
> >> I'm not a fan of the --continue switch.
> > 
> > I'm not either, but I haven't heard a better answer yet.
> > 
> >> We could use the same approach than in merge, recording that we are
> >> doing something special and refuse to do most operation but a commit.
> >> A conflict during graft would ask you to resolve and commit. Using
> >> commit would allow to use the existing UI to tweak the default value
> >> if needed.
> > 
> > This is tricky because it implies commit has to know that we were in the
> > middle of a graft to find the commit details. And of course, it needs to
> > know how to continue a multi-revision graft that breaks in the middle.
> > 
> > I'm somewhat tempted to make graft only work on one changeset at a time
> > so that you can't accidentally make a huge mess that can't be rolled
> > back. This would make it more similar to backout.
> > 
> >> After the commit, the graft will continue until it complete.
> >> Interactive (-i, --interactive) graft would ask for an explicit commit
> >> for each grafted changeset.
> >> 
> >> A more stupid question is : "how is graft different from a rebase
> >> --keep where you can specify where to stop your rebasing ?"
> > 
> > a) it's built into core
> > b) it's easier to use
> > 
> > In terms of (b), graft is more natural in that it pull changesets from
> > 'there' to 'here', while rebase by default moves your current branch
> > (and has a bunch of confusing options if that's not what you want to
> > do).
> > 
> > It's also probably simpler to think of rebase as being a bunch of grafts
> > + a strip at the end rather than thinking of graft as a special
> > not-yet-implemented rebase mode.
> 
> Making sure I understand right: graft would essentially be a smarter
> transplant without some of the state tracking? (This sounds like
> something I've been meaning to do...)

As written, it avoids grafting duplicates by adding an extra element.

-- 
Mathematics is the supreme nostalgia of our time.