Re: [Monotone-devel] Re: Trying to understand the ideas behind cherrypicking...

[Bruce Stephens]

Richard Levitte - VMS Whacker <address@hidden> writes:

> In message <address@hidden> on Thu, 25 Nov 2004 17:14:30 +0000, Bruce 
> Stephens <address@hidden> said:

[...]

> monotone> For example, if you subsequently do a star-merge (or
> monotone> presumably other such merges) from that branch, Arch will
> monotone> start from the changeset after the last cherrypicked
> monotone> changeset.  (I'm not quite sure how it does it, exactly, but
> monotone> someone said it did (I've never had occasion to use the
> monotone> feature).)
>
> Hmm, I'm not really well acquainted with arch (there are just too many
> ways to do every darn thing!!!), so I can't really say I know exactly
> what star-merge does.  If I was to implement a merge that supports the
> presence of cherrypicked patches, I'd still start with the same common
> ancestor as usual, but when applying changes along the edge of the
> branch I'm merging from (so to say), I'd skip over the changesets that
> have been cherrypicked.  Could that be what arch does?

My guess is that by default it just takes each changeset (which is
basically a line-based patch, so it can be applied in this way) and
applies it.  star-merge has a --three-way option, and I guess then it
has the behaviour you suggest.

[...]

> Command name ideas:
>
>  cherrypicking:                       monotone transplant ID [BRANCH]
>  disallow certain revisions:  monotone disallow transplant ID [BRANCH]

I don't much like "transplant", but I'm not quite sure why.  Why not
just use an optional argument (or arguments) to propagate?  OK,
propagate (like merge) doesn't currently work on a working tree, so
that doesn't quite work, but I think that's probably wrong (and
Graydon seemed to agree).

> The second command is quite tricky, because there's really no place
> to put a cert for disallowed IDs.

I agree.  You could create a cert that mentions the relevant changeset
and the branch name on which you don't want to apply it, but I agree
it doesn't feel right.

> monotone> And maybe it would be useful to give a way to indicate
> monotone> dependency, so it would be awkward to cherrypick a
> monotone> particular changeset that really depends on others (monotone
> monotone> would by default drag in the dependencies too).
>
> *eeeep*

OK, maybe not.  I guess if you end up requiring 4 different
changesets, then that's a good sign that creating a branch would be a
good idea.