[BUG] Merging an MD into a different branch causes a cherrypick

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> I feel like it should be possible to merge a MD into a branch that it is not
>> directed towards, as long as you have the required revisions (this may be
>> contentious, so I'm stating it up front.)
> 
> Agreed.  But a cherrypick is a kind of merge.
> 
>> However if you create a MD against one branch, it actually creates a
>> cherry-pick against that branch (by default). So when I merge it into a
>> different branch, it fails.
> 
> 
>>  bzr merge ../fixed_feature_b.patch
> 
>> Will fail.
> 
> Can you please describe the failure?
> 

It cherry picks the request rather than actually merging the branch. Which
means that the patch conflicts, rather than applying cleanly (since it was
built on top of the other changes).

...

>> I *think* the solution would be to not set "base_revision_id" as the merge base
>> unless the user actually requested a cherry pick from the beginning.
> 
> I don't think we can reasonably show a preview patch if we can't predict
> what will happen when the merge directive is merged.
> 

I think that if the MD is merged against the target branch, it should produce
exactly the correct diff. But that should not prevent it from being merged
elsewhere.

>> At a minimum, I think "bzr merge ../foo.patch" should give a warning or some
>> sort of indication that it is doing a cherry pick, rather than a regular merge.
> 
> That would be fine.
> 
>>   affects bzr
>>   status triaged
>>   importance medium
> 
> I feel that this is too soon to be marking this as a bug.  It should be
> obvious that this is the intended behavior, whether or not you feel it's
> the correct behavior.

I feel like if we decide it is not a bug we can mark it Rejected. But at them
moment *I* feel like it is a bug. Also, I felt like someone else might run into
it, and at least this way we have a workaround listed/discussion recorded for
posterity.

I'm not sure why you have such a high barrier to creating new bugs. Maybe it is
just because I marked it Triaged?

> 
> Also, if I hit reply all, that will include new at bugs.launchpad.net.
> Will that be bad?
> 
> Aaron

I think it will either just complain that you didn't give a product (because it
is in the quoted section), or it will auto-attach your reply to the discussion.

I suppose I could BCC it, though I actually did want the discussion to go to
the bug tracker as well as the mailing list.

Also, to extend this case a little bit.

What if Joe starts with 10 revisions, and I branch from there.
I commit 5 changes, which Joe merges without me realizing (or updating my copy
of his branch.) He also has to do a little bit of work to fix my changes.
I then do a few more changes, and send it.

At that point, if he merged my branch, he would get no conflicts. But because
merge directives force the base revision, he will end up getting conflicts on
the first 5 changes which he has already merged. I didn't put together a test
case to prove this, but I believe it is correct.


Basically, in *my* mind, doing:

cd branch
bzr send -o ../foo.patch

cd ../other-branch
bzr merge ../foo.patch

should be 100% equivalent to doing

cd ../other-branch
bzr merge ../branch

If I forced a cherry pick bundle with

cd branch
bzr send -r -2..-1 -o ../foo.patch

then it should be equivalent to doing
cd ../other-branch
bzr merge -r -2..-1 ../branch

regardless of what the submit_branch is.

That is also how Bundles worked (versus merge directives).

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHJ553JdeBCYSNAAMRAl35AKCTpLwG52QS5lchkMJ3A4TtKfOocgCdHK0V
h+0nKc2utBSN9rzID2axTCI=
=AbJL
-----END PGP SIGNATURE-----