[MERGE/RFC] Merge prefers to use submit branch

John Arbash Meinel john at arbash-meinel.com
Thu Dec 20 14:21:51 GMT 2007


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

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> I'm okay with using submit location first, but I think it mostly point
>> to us needing a merge location, separate from parent location.
> 
> I would rather avoid having too many associated locations.  I don't
> think we need a merge location if we have a submit location.
> 
>> I also know there are people who do:
> 
>> bzr pull
>> # oops, it failed
>> bzr merge
> 
> Sure, but for me that is a rare case.
> 
>> Yes, they could use bzr merge --pull, but for people who are used to
>> doing the former, this may be a surprising change.
> 
> Could you map out this use case a bit more?

We've had several people who have stated they don't care about the distinction
between merge and pull. Which is why we accepted the patch for "bzr merge
- --pull" in the first place.

At the moment we have:

% bzr pull
These branches have diverged.  Try using "merge" and then "push".

If they have been using 'bzr pull' (no url) to grab changes from upstream, it
would be nice if "bzr merge" could use the same location.

I guess if they don't have a submit location, that still works (since you fall
back to the parent location).

It isn't a workflow *I* use. I'm mostly concerned about having us make other
workflows more difficult by tuning Bazaar for use in a star topology. Or maybe,
I should say *our* star topology. Because people could still be in a star, and
want to use "bzr pull" over bzr merge when possible.

I think people could adapt, and ones that want "bzr pull || bzr merge" can
switch to "bzr merge --pull". I'm not sure that it is a discoverable option.
And certainly I don't think our tutorials cover it. (Because most of us
consider mainlines a thing to preserve.)

> 
>> I'm also not sure that people will commonly do:
> 
>>   bzr merge joe
>>   bzr send
> 
>> And want it to go to joe.
> 
> That is the only way I operate.  Joe is bzr.dev for me.
> 
> Typically, if you merge from a single location, you merge from the
> branch where you ultimately plan to submit your changes.
> 

Well, there are people who develop around a checkout of trunk rather than using
a PQM. I suppose the submit location doesn't matter in a case like that, since
trunk is always going to be merging from a different location.

Personally, I don't have a need for this, as I've already shell aliased:

alias BMD='bzr merge $HOME/bzr/bzr.dev'
alias BCM='bzr commit -m "merge bzr.dev `bzr revno $HOME/bzr/bzr.dev`"'
alias BCMD='bzr merge-directive $HOME/dev/bzr/bzr.dev >
$HOME/dev/bzr/patches/`basename $(pwd)`.patch'

I've used 'bzr send' from time to time, but there are still some limitations.

1) Often when I've been working on something, while the test suite is running,
I start writing the [MERGE] email. Which means I may or may not already have a
commit that I'm going to send.

2) I've been doing most of my development on my Mac, where Thunderbird doesn't
work properly with bzr send. So I use "bzr send" when I'm doing a quick patch.
(I actually prefer writing in ViM to T-bird anyway, but I certainly prefer
reading my email in T-bird.)

3) The random names given to 'bzr send' patches bothers me, but only a little.
Mostly when I go to merge someone else's patch without using BB. I download the
patch to ~/dev/bzr/patches/*.patch, and then I have to look closely to see what
the name was for when I 'bzr merge ...'.

I've named my branches by feature, it would be nice to name the patch by the
same. (Which is what my alias does.)

4) Since my target branch is always bzr.dev anyway, the BCMD alias knows where
to look. And is shorter to type. And works whether or not I've done a merge
before. (cbranch used to set the parent for me, but you changed that since I
work with heavy checkouts instead of lightweight ones.)


So for the 2 people who have said anything, 1 feels it is an improvement, and
it won't effect the other. I'm just concerned that 2 samples is not very
representative.

If you feel like you've thought enough about possible ramifications, you're
welcome to merge it. Obviously it meant enough to you to put in the effort.

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

iD8DBQFHanp+JdeBCYSNAAMRAvkAAJ4j+iqO0oMdCk82UCUKjxROLbLgbwCgyedt
w8XjrRfGGp5C3Uo0xkEB/GM=
=WUju
-----END PGP SIGNATURE-----



More information about the bazaar mailing list