BUG 1.7.9: git branch fails to create new branch when --edit-description is used
This should work, but doesn't:
% git branch
* master
% git branch --edit-description blarf [Edit description and exit editor normally] % cat .git/BRANCH_DESCRIPTION
I like blarf
# Please edit the description for the branch
# blarf
# Lines starting with '#' will be stripped. % git branch -a
* master
Where is branch blarf?
Creating the branch and editing the description afterwards works correctly:
% git branch blarf
% git branch --edit-description blarf
% git branch -a
blarf
* master
% cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[branch "master"]
description = I like pie\n
[branch "blarf"]
description = I like blarf\n
Mark Jason Dominus [email protected]
Quoted 14 lines · Mark Jason Dominus
This should work, but doesn't:
% git branch
* master
% git branch --edit-description blarf [Edit description and exit editor normally] % cat .git/BRANCH_DESCRIPTION
I like blarf
# Please edit the description for the branch
# blarf
# Lines starting with '#' will be stripped. % git branch -a
* master
Quoted 1 line
Where is branch blarf?
You haven't created one in that sequence yet.
This is more of a documentation bug.
As the SYNOPSIS section makes it clear, the '--edit-description' is a separate mode from showing (the first group), creating or repointing (the second), or renaming (the third).
After that you should be able to say "git branch blarf" and view its description.
Quoted 20 lines · Junio C Hamano
Quoted 14 lines · Mark Jason Dominus
This should work, but doesn't:
% git branch
* master
% git branch --edit-description blarf [Edit description and exit editor normally] % cat .git/BRANCH_DESCRIPTION
I like blarf
# Please edit the description for the branch
# blarf
# Lines starting with '#' will be stripped. % git branch -a
* masterQuoted 1 line
Where is branch blarf?
You haven't created one in that sequence yet.
Quoted 8 lines
This is more of a documentation bug.
As the SYNOPSIS section makes it clear, the '--edit-description' is a separate mode from showing (the first group), creating or repointing (the second), or renaming (the third).
After that you should be able to say "git branch blarf" and view its description.
Given this design, shouldn't "git branch --edit-description" fail if the branch doesn't already exist?
Shouldn't it also resolve ambiguous reference names?
Michael
Signature · 3 lines
Michael Haggerty [email protected] http://softwareswirl.blogspot.com/
Quoted 10 lines · Michael Haggerty
Quoted 10 lines
Quoted 1 line
Where is branch blarf?
You haven't created one in that sequence yet.
This is more of a documentation bug.
As the SYNOPSIS section makes it clear, the '--edit-description' is a separate mode from showing (the first group), creating or repointing (the second), or renaming (the third).
Quoted 5 lines
Quoted 2 lines
After that you should be able to say "git branch blarf" and view its description.
Given this design, shouldn't "git branch --edit-description" fail if the branch doesn't already exist?
The only use scenario in the original design was to have a way to store the description given a branch name, and giving a description to a branch that does not yet exist is outside the scope of the design. So it all boils down to what is the most convenient and the simplest to explain.
We could error it out (i.e. you cannot name a thing that does not yet exist), or we could consider it is a convenience feature that you can prepare a description even before you create one, or we could even tweak it more like "-t $name" that tries to work both on existing one (without changing any base) or non-existing one, creating it while at it. The last approach historically is the most error prone (we had numerous bugs in the create_branch() helper after it started allowing an existing branch when updating the "track" information) and I would rather not go that route if we can avoid it.
Honestly speaking, I haven't formed an opinion.
Quoted 1 line
Shouldn't it also resolve ambiguous reference names?
As this mode, just like other modes of "git branch" _always_ takes a branch name, I do not think there is any "ambiguous reference name".
You give $name to it, and it should always mean refs/heads/$name, and there shouldn't be any DWIMming to something like refs/heads/mh/$name
Or do you have other kinds of ambiguity in mind?
Quoted 7 lines · Junio C Hamano
Quoted 2 lines
Given this design, shouldn't "git branch --edit-description" fail if the branch doesn't already exist?
The only use scenario in the original design was to have a way to store the description given a branch name, and giving a description to a branch that does not yet exist is outside the scope of the design. So it all boils down to what is the most convenient and the simplest to explain.
How do we define "branch exists"? That the ref exists? What about a HEAD that points to a branch-to-be-born?
Specifically, I am wondering whether this:
$ git init $ git branch --edit-description
should work. Right now it edits the description for "master", even though you haven't yet committed to it.
-Peff
Quoted 33 lines · Junio C Hamano
Quoted 10 lines · Michael Haggerty
Quoted 10 lines
Quoted 1 line
Where is branch blarf?
You haven't created one in that sequence yet.
This is more of a documentation bug.
As the SYNOPSIS section makes it clear, the '--edit-description' is a separate mode from showing (the first group), creating or repointing (the second), or renaming (the third).
Quoted 5 lines
Quoted 2 lines
After that you should be able to say "git branch blarf" and view its description.
Given this design, shouldn't "git branch --edit-description" fail if the branch doesn't already exist?
The only use scenario in the original design was to have a way to store the description given a branch name, and giving a description to a branch that does not yet exist is outside the scope of the design. So it all boils down to what is the most convenient and the simplest to explain.
We could error it out (i.e. you cannot name a thing that does not yet exist), or we could consider it is a convenience feature that you can prepare a description even before you create one, or we could even tweak it more like "-t $name" that tries to work both on existing one (without changing any base) or non-existing one, creating it while at it. The last approach historically is the most error prone (we had numerous bugs in the
create_branch()helper after it started allowing an existing branch when updating the "track" information) and I would rather not go that route if we can avoid it.
Quoted 1 line
Honestly speaking, I haven't formed an opinion.
I vote for an error. Otherwise a typo in the branch name would lead to the description's apparent disappearance into Nirvana. An error would, for example, have made it clear to the OP what was happening.
A more useful option might be
git branch --with-description <branchname> [<start-point>]
i.e., that a branch's description can be set at the same time as the branch is created.
Quoted 9 lines
Quoted 1 line
Shouldn't it also resolve ambiguous reference names?
As this mode, just like other modes of "git branch" _always_ takes a branch name, I do not think there is any "ambiguous reference name".
You give $name to it, and it should always mean refs/heads/$name, and there shouldn't be any DWIMming to something like refs/heads/mh/$name
Or do you have other kinds of ambiguity in mind?
OK, I wasn't aware that only local branches can have descriptions attached to them. Given that fact, you are correct that DWIMming doesn't make sense.
Michael
Signature · 3 lines
Michael Haggerty [email protected] http://softwareswirl.blogspot.com/
Quoted 18 lines · Michael Haggerty
Quoted 11 lines · Junio C Hamano
We could error it out (i.e. you cannot name a thing that does not yet exist), or we could consider it is a convenience feature that you can prepare a description even before you create one, or we could even tweak it more like "-t $name" that tries to work both on existing one (without changing any base) or non-existing one, creating it while at it. The last approach historically is the most error prone (we had numerous bugs in the
create_branch()helper after it started allowing an existing branch when updating the "track" information) and I would rather not go that route if we can avoid it.Quoted 1 line
Honestly speaking, I haven't formed an opinion.
I vote for an error. Otherwise a typo in the branch name would lead to the description's apparent disappearance into Nirvana. An error would, for example, have made it clear to the OP what was happening.
Quoted 6 lines
A more useful option might be
git branch --with-description <branchname> [<start-point>]i.e., that a branch's description can be set at the same time as the branch is created.
So you are saying either option 1 or 3 is preferrable, while I was saying I would rather avoid 3 if we could avoid it. Is that the short version?
Quoted 22 lines · Junio C Hamano
Quoted 20 lines · Michael Haggerty
Quoted 11 lines · Junio C Hamano
We could error it out (i.e. you cannot name a thing that does not yet exist), or we could consider it is a convenience feature that you can prepare a description even before you create one, or we could even tweak it more like "-t $name" that tries to work both on existing one (without changing any base) or non-existing one, creating it while at it. The last approach historically is the most error prone (we had numerous bugs in the
create_branch()helper after it started allowing an existing branch when updating the "track" information) and I would rather not go that route if we can avoid it.Quoted 1 line
Honestly speaking, I haven't formed an opinion.
I vote for an error. Otherwise a typo in the branch name would lead to the description's apparent disappearance into Nirvana. An error would, for example, have made it clear to the OP what was happening.
A more useful option might be
Quoted 7 lines
Quoted 4 lines
git branch --with-description <branchname> [<start-point>]i.e., that a branch's description can be set at the same time as the branch is created.
So you are saying either option 1 or 3 is preferrable, while I was saying I would rather avoid 3 if we could avoid it. Is that the short version?
Not quite. I agree that "--add-description" should fail if the branch already exists. But I was suggesting that there be a new *different* option that can be used when creating a branch. "--with-description" is probably not a great name, but I think it is a good idea that it be spelled differently than "--add-description". Perhaps even "--message", even though the abbreviation "-m" is precluded by the existing "-m" option.
Michael
Signature · 3 lines
Michael Haggerty [email protected] http://softwareswirl.blogspot.com/
Quoted 6 lines · Michael Haggerty
Quoted 2 lines · Junio C Hamano
Michael Haggerty <[email protected]> writes:
I vote for an error. Otherwise a typo in the branch name would lead to the description's apparent disappearance into Nirvana. An error would, for example, have made it clear to the OP what was happening.
I agree with this statement.
Unless or until we update --edit-description to create a new branch when given a name of a branch that does not exist, the existing behaviour is simply an accident waiting to happen.