All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: Mark Jason Dominus <mjd@plover.com>, git@vger.kernel.org
Subject: Re: BUG 1.7.9: git branch fails to create new branch when --edit-description is used
Date: Sun, 29 Jan 2012 11:11:28 +0100	[thread overview]
Message-ID: <4F251B50.5080602@alum.mit.edu> (raw)
In-Reply-To: <7v39azxb5l.fsf@alter.siamese.dyndns.org>

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

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

  reply	other threads:[~2012-01-29 10:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-27 21:52 BUG 1.7.9: git branch fails to create new branch when --edit-description is used Mark Jason Dominus
2012-01-27 23:21 ` Junio C Hamano
2012-01-28  6:46   ` Michael Haggerty
2012-01-28  7:27     ` Junio C Hamano
2012-01-29  3:18       ` Jeff King
2012-01-29  6:30       ` Michael Haggerty
2012-01-29  6:42         ` Junio C Hamano
2012-01-29 10:11           ` Michael Haggerty [this message]
2012-01-29 21:49         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F251B50.5080602@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mjd@plover.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.