[RFC] New core command: graft

Gilles Moris gilles.moris at free.fr
Wed Oct 12 01:51:26 CDT 2011

On Tuesday 11 October 2011 11:15:51 pm Laurens Holst wrote:
> Op 10-10-2011 21:40, Antoine Pitrou schreef:
> >> 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.
> >
> > I guess there's a tension between providing a light-weight command
> > that doesn't touch the rest of the core (like "hg transplant") and
> > something more sophisticated that addresses the use cases of a larger
> > base of people.
> I think that’s a rather bold assumption, and at least one that I don’t
> really identify with. What you are basically asking for is something
> very similar if not identical to the ‘committer’ field that git has. I
> think it does not really add value to have this information, if you want
> to have a fireman contact it is better to use a push log.

You are wrong here. In my organization, I am pretty the only one actually 
pushing in the main repository (I think this is the same with Matt for the HG 
main repo). And I am not the one who graft changes from branch to branch.
It would be good to be able to track who took the responsibility to graft and 
when, so to reset the commit user and date to the current ones when grafting.

> As for attaching metadata pointing to the original changeset to the
> commit; note that this original changeset may very well not be public,
> so this probably does not make sense to automatically add this by
> default. Also encoding this into the commit metadata kind of conflicts
> with the whole line of thought of thinking about rebase in terms of a
> sequence of grafts and a strip.

Rebase and strip are non-core commands. So they don't play in the game of 
graft which will be a core command.
That metadata 'graft_source' (underscore?) is already present in Matt's 
original patch in ctx.extra(). It's very useful as it allows the graft 
command to determine if the graft has already applied to the branch.

I am concerned that any people that will want to reset the commit user or 
date, will have to use the --no-commit. And once done, you loose this 
graft_source, with absolutely no way to re-introduce it at the next commit.

> What I do think would add value is to add a line to the commit message
> editor popup that mentions the changeset of the original, if that is
> easily possible (otherwise such a function could always be added later).

Yes that would be an option. Another would be to add a --grafted-from option 
to commit to add the graft_source, but I don't think Matt will be pleased 
with that. However, that would be a trivial change to commit.

> ~Laurens


More information about the Mercurial-devel mailing list