[RFC] New core command: graft

Laurens Holst laurens.nospam at grauw.nl
Tue Oct 11 16:15:51 CDT 2011


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.

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.

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).

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Working @ www.roughcookie.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4332 bytes
Desc: S/MIME cryptografische ondertekening
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111011/973c4631/attachment.bin>


More information about the Mercurial-devel mailing list