[RFC] New core command: graft
mpm at selenic.com
Wed Oct 12 02:03:37 CDT 2011
On Wed, 2011-10-12 at 08:51 +0200, Gilles Moris wrote:
> 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
This will probably just become 'source'.
> 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.
You'll be pleased to hear that I've added an --edit option to launch an
editor (or an automated tool) on the commit messages. And I've gone
ahead and done this for rebase, transplant, and import too. I'll add
date and user options too.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel