[PATCH 3 of 3 branch --new] branch: deprecate creation of branches without --new

Augie Fackler raf at durin42.com
Thu Apr 16 10:43:11 CDT 2015


On Apr 16, 2015, at 11:37 AM, Mads Kiilerich <mads at kiilerich.com> wrote:

> On 04/15/2015 06:36 PM, Augie Fackler wrote:
>> On Wed, Apr 15, 2015 at 05:14:52PM -0400, Mads Kiilerich wrote:
>>> # HG changeset patch
>>> # User Mads Kiilerich <madski at unity3d.com>
>>> # Date 1429132330 14400
>>> #      Wed Apr 15 17:12:10 2015 -0400
>>> # Node ID 97c2568dfc479675b96b84ea3b6ae7ec55f5560c
>>> # Parent  f832f9a6081a18eb3f54e1f2718ab753cff9d50c
>>> branch: deprecate creation of branches without --new
>>> 
>>> --new is more explicit and not treacherous for git users.
>> How? --new does nothing to help git users understand that branches are
>> global and permanent. This series seems like it'll make the problem
>> for git users worse, not better.
> 
> I have been told (when other changes were rejected) that git users expect "$toolname branch foo" to switch to a branch foo - they don't expect it to create a new branch.

Whomever told you that is very much mistaken. Quoting `man 1 git-branch`:

“””
GIT-BRANCH(1)                     Git Manual                    GIT-BRANCH(1)

[...]
SYNOPSIS
       git branch [--color[=<when>] | --no-color] [-r | -a]
               [--list] [-v [--abbrev=<length> | --no-abbrev]]
               [--column[=<options>] | --no-column]
               [(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]
       git branch [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
[...]

       The command's second form creates a new branch head named <branchname>
       which points to the current HEAD, or <start-point> if given.

       Note that this will create the new branch, but it will not switch the
       working tree to it; use "git checkout <newbranch>" to switch to the
       new branch.

"""

This both matches my memory and my experimentation.

> That is why we can't let our branch creation be quiet but have to tell the users that we just did what they (perhaps unintentionally) told us to do. And that is why we must take extra care to protect the user from reviving branches when he perhaps rather would update to the existing head.

Yeah, it’s demonstrably false that git users would expect anything other than reset or checkout to change their current branch.

> 
> I think that we by making branch creation more explicit can let it be what we would like it to be - and allow branch revival without any ugly use of --force.
> 
> People who read the documentation and learned the --new option will probably also have a basic understanding of what Mercurial branches are so we don't have to show the "Mercurial branches are not what you think it is - do you want to use git?"-ish warning.

I disagree. The problem is a terminology one, not a “what command do I run” one. VCS users are, as a rule, very used to cargo-culting command strings, and if someone is trying to "make a new branch”, that’s what they’ll do, even if what they wanted was a bookmark. For git refugees, the big problem is that their mental construct of a branch matches up with bookmarks, not branches.

> 
> /Mads

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150416/2d6cf0e7/attachment.pgp>


More information about the Mercurial-devel mailing list