Re: BUG 1.7.9: git branch fails to create new branch when --edit-description is used

[Michael Haggerty <mhagger@alum.mit.edu>]

On 01/28/2012 08:27 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>>>> 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.
>>
>> 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.

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.

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

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/