[RFC] New core command: graft
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.
More information about the Mercurial-devel