Andrew Ardill <andrew.ardill@xxxxxxxxx> writes:
> Since git branch has the default behaviour to create a branch 'in the
> background' it makes sense to fail when trying to create a new branch
> this way from an empty branch. The error message should be improved to
> handle this edge case in a nicer way. If we allow for renaming empty
> branches (described below) then the message can be even more helpful.
> Instead of
> fatal: Not a valid object name: 'master'.
> perhaps
> fatal: Cannot create branch 'foo' from empty branch 'master'. To
> rename 'master' use 'git branch -m master foo'.
The first new sentence is a definite improvement, but I do not think
the advice in the second sentence is necessarily a good idea,
because it is dubious that the user is likely to have wanted to
rename 'master' to something else. "git branch foo master" (or its
moral equivalent "git checkout -b foo" while on master) is a wish to
have a history that ends in 'foo' *forked* from history of 'master',
but because you do not even have anything on 'master' yet, you
cannot fork the history, as you explained earlier (snipped). In
that sense, 'empty branch' is a slight misnomer---as far as "git
branch foo master" is concerned, the 'master' branch does not yet
exist (and that is why we often call it an "unborn branch", not
"empty").
fatal: cannot fork master's history that does not exist yet.
would be more accurate description of the situation.
> So explicitly, I am proposing the following behaviour changes:
>
> When trying to create a new branch without specifying a start point,
> if HEAD points to an empty branch, error with a more useful message
> that assumes the user might want to rename the empty branch.
I do not think that is the right assumption in the first place. It
is very likely that the user does not yet know how Git works when
she attempts to fork from a history that does not exist. It is also
very likely that she is expecting, after "git branch foo master"
succeeds when 'master' is yet to be born, have two branches 'foo'
and 'master', so that "git checkout foo" and "git checkout master"
can be done subsequently.
But that expectation is wrong, and it would help the user in the
longer run to correct that expectation. "We assume you wanted to
rename 'master' to 'foo'" is a logical consequence that changing
HEAD that points at an unborn 'master' to point at an unborn 'foo'
is the best (or closest) thing the user can do, *if* the user
understands that the current branch being unborn is a special state
and there can only be one such unborn branch (that is, the current
one). The user who gets this error message, however, clearly does
not understand that, so it is not a logical consequence to her at
all. The advice does not help her, but instead invites "No, I did
not want to rename it, I wanted to have 'foo' without losing
'master'", leading to even more confusion.
> When trying to create a new branch whilst specifying an empty branch
> as the start point,
> if HEAD points to the same empty branch that is listed as the start
> point, error with a more useful message that assumes the user might
> want to rename the empty branch.
> otherwise error due to invalid ref
See above (for all the other cases, too).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html