[RFC] New core command: graft
durin42 at gmail.com
Sun Oct 9 20:51:35 CDT 2011
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
>>> - 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
> 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...)
> Mathematics is the supreme nostalgia of our time.
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
More information about the Mercurial-devel