Does anyone use named branches?

[Christian Boos]

Adrian Buehlmann wrote:
> On 15.10.2009 01:18, Bryan O'Sullivan wrote:
>   
>> I keep wanting to like named branches, but I get consistently pushed
>> away from them.
>>
>> In a world without branch naming, anonymous branches are implicitly
>> named "default".
>>
>> Approximately 100% of the time, except during occasional brief merges, I
>> want to have just one named branch active in any given repository. So if
>> I check out my "1.2" branch, I want it to contain the named branch
>> "1.2", and I'd really like Mercurial to update to the tip of that branch
>> when I clone it. But instead, it updates to the tip of the "default"
>> branch, and I then have to manually update to the tip of "1.2" by hand
>> afterwards.
>>     
>
> In the case of doing a local clone, it could indeed read the branch currently
> set in the source repo's working dir and update the new clone to that branch
> instead of to 'default'.
>
> IMHO, this behavior change would make a lot of sense and it wouldn't hurt
> those users who don't use named branches anyway (since their named branch
> in the source repo is always 'default' anyway).
>   

I'd second that, this is also my experience.

> In case there are concerns about changing the default behavior, this new
> behavior could be introduced by using a config option, let's say 'clonebranch'
> in section [ui], with a default of False. Setting it to True would checkout
> the branch set in the source repo's working dir when doing a local clone.
>
>   

When doing a clone, isn't the .hgrc [paths] default = ... set to the 
source of the clone?
Likewise, we could imagine a [paths] default-update = ... entry which 
could be set to the branch name of the tip of the clone source, or more 
precisely, to the branch name of the revision used for cloning the 
source repository, useful in case of `hg clone -r <branch>`.

The advantage I see to this approach is that it would be very clear why 
the "default" behavior of `hg update` is changed for a given repository, 
and that it could be corrected or modified very easily (removing the 
setting would make `hg update` use the tip of the "default" branch as 
usual).

>> I find that this behaviour makes named branches sufficiently unappealing
>> and surprising that I never use them and always advocate against their
>> use, even though they're notionally extremely useful in a
>> medium-to-large team. Basically, the "clone, then remember to update by
>> hand" requirement screams to me "and here's where you'll make lots of
>> mistakes because you'll forget to take this step 40% of the time".
>>
>>     

I'd say 60% for me, and while I find this annoying as well, that doesn't 
prevent me from using the named branches and finding them extremely 
useful ;-)

>> Am I alone? Does anyone actually like the current behaviour?
>>     
>
> Also, we could add an update option to clone (as we already have in pull):
>
> hg clone -u 1.2
> hg clone --update 1.2
>   

With my proposal above, `hg clone -r 1.2` would just do that.

-- Christian