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

login
register
mail settings
Submitter Mads Kiilerich
Date April 15, 2015, 9:14 p.m.
Message ID <97c2568dfc479675b96b.1429132492@localhost.localdomain>
Download mbox | patch
Permalink /patch/8693/
State Rejected
Headers show

Comments

Mads Kiilerich - April 15, 2015, 9:14 p.m.
# HG changeset patch
# User Mads Kiilerich <madski@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.
Augie Fackler - April 15, 2015, 10:36 p.m.
On Wed, Apr 15, 2015 at 05:14:52PM -0400, Mads Kiilerich wrote:
> # HG changeset patch
> # User Mads Kiilerich <madski@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.


>
> diff --git a/mercurial/commands.py b/mercurial/commands.py
> --- a/mercurial/commands.py
> +++ b/mercurial/commands.py
> @@ -1060,7 +1060,7 @@ def bookmark(ui, repo, *names, **opts):
>       _('set branch name even if it shadows an existing branch')),
>      ('C', 'clean', None, _('reset branch name to parent branch name')),
>      ('n', 'new', '', _('mark working directory as creating new branch'))],
> -    _('[-fC] [NAME]'))
> +    _('[-fC]'))
>  def branch(ui, repo, label=None, **opts):
>      """set or show the current branch name
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Mads Kiilerich - April 16, 2015, 3:37 p.m.
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@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. 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.

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.

/Mads
Augie Fackler - April 16, 2015, 3:43 p.m.
On Apr 16, 2015, at 11:37 AM, Mads Kiilerich <mads@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@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
Mads Kiilerich - April 16, 2015, 4:20 p.m.
On 04/16/2015 11:43 AM, Augie Fackler wrote:
> On Apr 16, 2015, at 11:37 AM, Mads Kiilerich <mads@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@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.

http://selenic.com/pipermail/mercurial-devel/2014-August/061199.html

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

So it would be better to "rename" the 'branch' command to 'namedbranch' 
or the shorter and less branch-like 'name'?

Anyway, besides the constant "do you really want to use named branches" 
annoyance, I (or my users) just want a way to revive ancestor branches 
without having to use --force. Would you be fine with --new if it were 
as verbose as the existing branch creation?

/Mads
Augie Fackler - April 16, 2015, 4:22 p.m.
On Apr 16, 2015, at 12:20 PM, Mads Kiilerich <mads@kiilerich.com> wrote:

> On 04/16/2015 11:43 AM, Augie Fackler wrote:
>> On Apr 16, 2015, at 11:37 AM, Mads Kiilerich <mads@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@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.
> 
> http://selenic.com/pipermail/mercurial-devel/2014-August/061199.html
> 
>> 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.
> 
> So it would be better to "rename" the 'branch' command to 'namedbranch' or the shorter and less branch-like 'name'?

Probably, but then you're tiptoeing towards adding another thing in the glossary hg users need to know, which I'm not sure is better.

> 
> Anyway, besides the constant "do you really want to use named branches" annoyance, I (or my users) just want a way to revive ancestor branches without having to use --force. Would you be fine with --new if it were as verbose as the existing branch creation?

Yes, that seems fine.

> 
> /Mads

Patch

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -1060,7 +1060,7 @@  def bookmark(ui, repo, *names, **opts):
      _('set branch name even if it shadows an existing branch')),
     ('C', 'clean', None, _('reset branch name to parent branch name')),
     ('n', 'new', '', _('mark working directory as creating new branch'))],
-    _('[-fC] [NAME]'))
+    _('[-fC]'))
 def branch(ui, repo, label=None, **opts):
     """set or show the current branch name