[RFC] New core command: graft

[Matt Mackall]

On Mon, 2011-10-10 at 10:08 +0200, Gilles Moris wrote:
> On Monday 10 October 2011 12:23:38 am Matt Mackall wrote:
> > This is a command we discussed at the 1.5 sprint in Paris and almost got
> > finished there as a rebase feature, but then forgot about. Later, I went
> > and changed the merge core to make it simpler to do rebase's magic.
> >
> > Now I've finally decided to try resurrecting the 'graft' command idea as
> > a core command.
> >
> > The basic concept is similar to transplant, except:
> >
> > - it uses real 3-way merge logic rather than patching
> > - it doesn't work between different repositories
> >
> > The trick here is that rather than use the 'natural' merge ancestor, we
> > choose the parent of the grafted changeset.
> >
> > 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.
> 
> Hi Matt,
> 
> I am extremely happy to see this happen, thanks for it. I think the python 
> team will love it as well.
> I am even more happier to see that graft will be a core command.
> 
> For the UI, I would like to see:
>  -N --no-commit   : I would like to see that at least for single rev grafting,
>                     though it could be interesting for mutirevs grafting. This
>                     avoid any commit and just leave backports as local
>                     changes.
>                     Original commit message(s) could be left in
>                     .hg/last-message.txt
>                     for reference.

I'd really like to avoid these two, and would sooner force people to use
your -N:

>  -U --currentuser : to update the rev with the current user; another way would
>                     be to have this as an author in extra(), I remember having
>                     seen this concept, but this would IMO require some support
>                     to display in hg log. Not sure a '-u USER' option is worth
> 
>  -D --currentdate : same for the date

But I like this idea:

>  -e --edit        : as a replacement of the previous -N option and to avoid
>                     having to use MQ (non core) to edit commit messages.
>                     If the -N option could be implemented, then the '-e'
>                     option may be dropped.
> 
> Also seeing the graft source with hg log -v would be interesting.



-- 
Mathematics is the supreme nostalgia of our time.