[MERGE/RFC] Merge prefers to use submit branch

Erik Bågfors zindar at gmail.com
Fri Dec 21 02:56:43 GMT 2007


Without actually thinking about the workflow here. For me it feels  
like this. Pull is a mechanism to get changes from another branch to  
my branch, in most cases merge is also to get changes from another  
branch to this one. So it feels very logical to use the same default  
URL.

However, the submit branch is from this branch to another, so why  
would merge use it.

There may be good reasons, but it feel not logical.

/Erik

Sent from my iPhone

On 2007 dec 20, at 15.21, John Arbash Meinel <john at arbash-meinel.com>  
wrote:

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