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

Aaron Bentley aaron.bentley at utoronto.ca
Wed Oct 31 00:36:21 GMT 2007


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

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>> 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).

Let's not conflate cherry-picking with failure.

In your particular case, it caused conflicts you didn't want, but I
don't think that is the common case.  I think most of the time, a merge
directive will be a self-contained set of changes that, when done as a
cherry-pick, will apply cleanly to any reasonably recent version of the
source branch.

I think that if a full merge was performed, in the common case, it would
drag in a whole bunch of undesired and potentially unrelated changes.
It might be a clean merge, but it would not be a useful one.  And in
fact, applying un-asked-for older changes could introduce further
conflicts, instead of reducing conflicts.

I would be happy to add an option to make it behave as you're
suggesting.  Another way would be to allow "merge -r" to override the
merge directive.  However, I think the default I've chosen is likely to
be correct more often, and is the conservative choice.

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

That is a straw man.  No one is preventing it being merged.  Most of the
time, the cherry-pick will work just fine.  And even if there are
conflicts, having conflicts is different from being unable to merge at all.

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

And I feel now like I've been impugned, and now have to prove that it's
not a bug instead of getting the benefit of the doubt.

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

No, it is because I spent a bunch of time trying to decide what should
happen, and now, based on one experience, you've gone and marked it
wrong and bad before even bothering to discuss it, or find out what the
actual behavior is.  It's not nice or polite.

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

Well, it's not correct, so perhaps next time you should put together a
test case.

Cherry-picking is performed when the merge base is not part of the
ancestry of the head, but when the merge base is part of the ancestry of
the head, a merge base is selected using our standard base-selection
algorithms.

> 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

Well, I think that merge directives are used differently, and those
differences justify some differences in behavior.

In particular, the person applying a merge directive is rarely the
person who created it, and they will tend to be less familiar with the
revision history.  They will tend to want to apply the changes present
in the merge directive, but won't necessarily be interested in whatever
other changes are present in the branch.  They will need to rely on the
directive's base selection, because they can't easily make their own.

Because the person applying the directive is not the creator, they will
probably assess the value of the patch based on the preview.  This is
why I want the preview to be an accurate indicator, so that people can
trust it.  I am okay with it showing *more* changes than would actually
be performed, but I am not okay with it showing *fewer*.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHJ84F0F+nu1YWqI0RAjkFAJ9RGiaPBa69gNnq+Sf5eeuTQe21/wCeJY1x
9L0Jiu0YD+fGApkRYWNMWwc=
=NMAI
-----END PGP SIGNATURE-----



More information about the bazaar mailing list