Re: [Monotone-devel] Re: cherrypicking in monotone

[Larry Hastings]

William Uther wrote:

Hrm, I can think of another kludge too (and a kludge is just what you wanted, I know); can you make *-merge label b1 and b2 the same so that we get something that looks like this:

      a1*
     /| \
    / |  \
   a2 b1* a3
   | /|   |
   |/ |   b1*
  b3   \ /
   |    b4 <-- b4 has a * for unique-*-merge, not for multi-*-merge
  c1*

Now c1* has beaten b1*, so we're fine :).

N.B.  labelling the two b1's the same is not too bad (he says waving hands wildly).  One was machine generated from the other without conflicts.

But if I understand you properly, you don't want to do this.  The original b1 has changes from a1->a3 and a3->b1, the johnny-come-lately b1 (what used to be labeled b2) only has the changes from a3->b1.  So they're not the same patch; that's the whole point of the exercise.  If you wanted all the changes from a1->a3->b1, you wouldn't be using cherry-picking in the first place, you'd just merge with b1.

If monotone "labeled" b2 as b1, when you later merged b4 and c1 it would think c1 had already seen the changes from a1->a3.  I don't know how it would actually react; I'm still wrapping my head around these high-falutin' concepts.  But surely it would behave undesirably, yes?

Anyway, I don't think you could "label" b2 as b1 as you suggest.  The name of b2 is the SHA-1 hash of its "revision", and one of the fields in a "revision" is the "old revision", aka the parent.  b1's parent is a3, b2's parent is a1.  Since the text of the revision must be different, the SHA-1 must be different, so their names are different, qed.

(Or am I being dense?)


larry