[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: Trying to understand the ideas behind cherrypic
From: |
Bruce Stephens |
Subject: |
Re: [Monotone-devel] Re: Trying to understand the ideas behind cherrypicking... |
Date: |
Thu, 25 Nov 2004 19:42:09 +0000 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) |
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.
- [Monotone-devel] Trying to understand the ideas behind cherrypicking..., Richard Levitte - VMS Whacker, 2004/11/25
- [Monotone-devel] Re: Trying to understand the ideas behind cherrypicking..., Bruce Stephens, 2004/11/25
- Re: [Monotone-devel] Re: Trying to understand the ideas behind cherrypicking..., Richard Levitte - VMS Whacker, 2004/11/25
- [Monotone-devel] Re: Trying to understand the ideas behind cherrypicking..., Bruce Stephens, 2004/11/25
- Re: [Monotone-devel] Re: Trying to understand the ideas behind cherrypicking..., Jon Bright, 2004/11/25
- [Monotone-devel] Re: Trying to understand the ideas behind cherrypicking..., Bruce Stephens, 2004/11/25