elmentary (watson): merge (named) branches and/or bookmarks

Arne Babenhauserheide arne_bab at web.de
Mon Dec 19 21:23:26 UTC 2016


Bob Hood writes:

> On 12/18/2016 9:38 AM, Arne Babenhauserheide wrote:
>> Bob Hood writes:
>>> On 12/18/2016 2:57 AM, Arne Babenhauserheide wrote:
>>>> Bob Hood writes:
>>>>> On 12/17/2016 2:56 AM, Uwe Brauer wrote:
>>>>>> Sorry for such an elementary question again, but bookmarks drive my
>>>>>> crazy.
>>>>> Coming from Subversion, I had a hard time wrapping my head around the paradigm
>>>>> as well, until I realized one day that named branches in Mercurial are just
>>>>> /permanent bookmarks/. Like regular bookmarks, they automatically follow a
>>>>> head as commits are made, but the head they are tracking is /just never meant
>>>>> to be merged back into their parent branch/--hence,
>>>> What do you mean by that?
>>>>
>>>> It’s regular usage to merge a branch back into the parent branch.
>>>
>>> Of course. If my understanding is correct, bookmarks (and named branches) just
>>> track /logical/ branch points (separate heads).
>>>
>>> Here's the model that we use:  Developers work in a sandboxed named branch (a
>>> /permanently//separate/ head of development), which mirrors the main branch,
>>> and then builds from those isolated named branches are exposed to testing.
>>> When testing approves, the developer merges their work into the main branch,
>>> however, the separate head, like the bookmark tracking it /never goes away/.
>>> Hence, the permanently separate head, in the guise of the named branch, never
>>> terminates when it is merged back to the main branch.
>>>
>>> As I understand it, this is not true for a regular bookmark.  They can be
>>> removed, and hence the /logical/ branch they are tracking is terminated when
>>> the heads are merged, e.g.:
>> So what you mean by branch is "the information that there are different
>> tracks of development"?
>>
>> You can remove that by explicitly closing the branch:
>>
>>    $ hg commit --close-branch -m "MESSAGE"
>>
>> Then the branch becomes inactive. The information is still in history
>> but not visible in `hg branches` or `hg heads`.
>
> Indeed, "named branches" become inactive using the above command; e.g.:
>
>      ...
>      PluginMetadata             34632:f16327aeacc1
>      jon                        34339:d5179eb05c19
>      RadiosityExperiment        31080:a2b360111e2f
>      BxDF_Proving_Ground        28200:2e57dc4ccda4
>      NewNodalFeatures           24252:cfe6dd5a6705
> *    LW2017.0.1                 58654:f40d2ed84d27 (inactive)**
> **    default.matt               58626:6cc6d42e0ab2 (inactive)**
> **    LW2017.0.1.antti           58551:1efc975c8027 (inactive)**
> **    LW2017.davidf              56385:aea27e87a13f (inactive)**
> *    ...
>
> But they can never be removed, and are easily revived with a simple
> commit.

They cannot truly be removed, that’s true (and intended: the use case is
providing additional information to check retroactively why a certain
commit was added). But they do not show up in the branches, not even as
inactive (at least not in my version of hg).

If you "revive" them, you get discontinuous branches, which works.

> If I correctly understood what I read, regular bookmarks are /not/ retained in 
> repository, nor do they display with "hg branches", once /they/ have been 
> "closed," right?

They do not get closed but rather get deleted. The information is gone.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20161219/6f552178/attachment.asc>


More information about the Mercurial mailing list