[MERGE/RFC] Merge prefers to use submit branch

[Aaron Bentley]

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

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

I think I argued against it.

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

Bazaar works best in a star topology.  I do have some ideas for
improving annotate merge, so that mesh-merging is less of a mess.  But
right now, we should be encouraging star topologies.  And IMO, we should
be discouraging pull as a merge strategy.

If I had proposed creating a new stored location for remembering merges,
would these arguments still apply?  I suspect they would.  You'd still
have situations where pull used one location and merge used another.

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

Yes, that was the "single location" bit of my argument there.

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

To me, it feels like if you have created shortcuts for these things, we
should probably support them directly.  Because I expect other people
are also doing the same things repeatedly.

BMD => we need a default merge location that can differ from the pull
location.  It doesn't necessarily have to be the submit location

BCM => I don't know what to do about this one.  Maybe "merge
- --test-and-commit" ?

BCMD => I *think* this is equivalent to "bzr send -o
$HOME/dev/bzr/patches/$(bzr branch-nick).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.

There's always `send -o`.  Personally, I do bzr send, start composing
the email, and then if I end up doing a commit, I create a new merge
directive.

> 2) I've been doing most of my development on my Mac, where Thunderbird doesn't
> work properly with bzr send.

If you could elaborate, maybe I can fix it.

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

Oh, what do you think of the "editor" mail client then?

> 3) The random names given to 'bzr send' patches bothers me, but only a little.

It bothers me, too.  I'd rather have it use the branch-nick, and
autonumber them.  I just haven't figured out the right UI to enable that.

But let's say there was an -odir option that meant:
- - output to this directory
- - name the file $BRANCH-NICK-$AUTONUMBER.patch, where AUTONUMBER is
added to ensure uniqueness.

Would that be appealing to you?

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

If you get it out of email, eh?  I'm not sure what to suggest for that.
 It's pretty cool that you can merge directly from BB though, eh?

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

Yes.  I was just updating cbranch, and I found detritus from that
removal.  I set my submit branch in ~/locations.conf, so it always
defaults to bzr.dev.

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

I really, really want my default merge location to differ from my
default pull location.  The rest is negotiable.

It doesn't have to be the submit branch.  We can add a new default merge
location, if you're sure that's the right way to proceed.  I just find
that in my usage, the submit location is always set to my preferred
merge location.  Introducing a new location has some minor compatibility
issues, too.

I'd rather not introduce new locations if I can help it, because every
bit of metadata is something the user must manage sooner or later.  But
if that's what it takes to get your full approval, I can do that.

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

iD8DBQFHa9C40F+nu1YWqI0RAjpSAJ9jLSnKUqTAudf5nQN5kTJAMdUEtgCeMiF1
QnxldatEXJr1WOaraVUebsQ=
=HYGJ
-----END PGP SIGNATURE-----