Bazaar Mercurial Plugin to access BitBucket

[Martin Geisler]

David Muir <davidkmuir at gmail.com> writes:

> On 21/10/11 18:26, Stephen J. Turnbull wrote:
>> David Muir writes:
>>
>>  > That's why I brought it up. I consider it one of Mercurial's weak
>>  > points. Bazaar IMO has the advantage here as the default is to
>>  > merge without fast-forward,
>>
>> *blink*
>>
>> You mean you want
>>
>> 0 --- 1              ? = default
>>        \            /
>>         `- A --- B-'   = feature
>>
>> to merge to
>>
>> 0 --- 1 ------------ 2 = default
>>        \            /
>>         `- A --- B-'   = feature
>>
>> instead of
>>
>> 0 --- 1 --- A --- B   = feature, default
>>
>> ??  OK, now that you mention it, I can see how that might be useful.
>>
>> git-merge has a --no-ff (no fast-forward) option, so you're not the
>> only one who wants this.
>
> Which is why I was surprised to find that Mercurial does not support
> both workflows. When chatting in their IRC channel a while back, the
> response I got was "Why would you want to do that?/Looks like a misuse
> of the DAG", and then told me off for using git terms...

We've talked about allowing such trivial merges for normal changesets.
There is nothing in Mercurial that would break -- you can infact do it
right now if you use named branches.

The reason it's prevented right now is that it does indeed look like a
confusion: changeset B already has all the changes in 1, so merging with
1 is redundant. I understand that you can use such an empty merge to
document that A and B were "separate" from the mainline (even though
they really wasn't...).

>>  > but still has the option of doing `bzr merge --pull` if you want
>>  > that behaviour. With Mercurial there is no option to merge instead
>>  > of fast-forward, unless you're using named branches,
>>
>> Ah, so (at the implementation level, i.e., a node can't be on two
>> branches at the same time) you like named branches for precisely the
>> reason I hate them!<wink>
>
> Yes, the graph described above is exactly how I want it, and is how
> Bazaar behaves by default. It makes it much easier to see what
> changesets/revisions belong to a particular feature and when it was
> merged into trunk. I'm a visual person, and I like seeing those merge
> commits in qlog ;-)

In fact, you will see the same in Mercurial in real use: there will be
other children of 1 than A, and so you will have to do a proper merge
when you integrate the feature branch.

It is always easy to construct small mini-examples that show bad
features. The real test is how the system works when you really use it.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20111021/cacaa50d/attachment.pgp>