git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Erik Faye-Lund <kusmabite@googlemail.com>
To: Erick Mattos <erick.mattos@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 3/5] checkout --orphan: respect -l option always
Date: Wed, 26 May 2010 17:13:02 +0200	[thread overview]
Message-ID: <AANLkTikKAkwHYj6OvfEJM1YE8w2TZL2oeMBrj28V3CwX@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimT3sI3yuM8RZai-eWDk8Z5Rmc28RLGOx_i-RXa@mail.gmail.com>

On Wed, May 26, 2010 at 4:52 PM, Erick Mattos <erick.mattos@gmail.com> wrote:
> Hi,
>
> 2010/5/26 Junio C Hamano <gitster@pobox.com>
>>
>> Erick Mattos <erick.mattos@gmail.com> writes:
>> > @@ -684,8 +709,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
>> >       if (opts.new_orphan_branch) {
>> >               if (opts.new_branch)
>> >                       die("--orphan and -b are mutually exclusive");
>> > -             if (opts.track > 0 || opts.new_branch_log)
>> > -                     die("--orphan cannot be used with -t or -l");
>> > +             if (opts.track > 0)
>> > +                     die("--orphan should not be used with -t");
>>
>> Why s/cannot/should not/?  Just being curious.
>
> I have typed that text, not changed the original so this is not a fix
> to your text.  Anyway for me "should not" is more polite, like "you
> should not yell" meaning you really can not do it.  Or "you should not
> disrespect the captain".

I don't think it makes sense to try and be polite when we're actually
refusing... "should not" implies that it possible but not recommended.
And in this case it's impossible, because we die()...

-- 
Erik "kusma" Faye-Lund

  reply	other threads:[~2010-05-26 15:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-22  0:28 [PATCH 0/5] checkout --orphan improvements Erick Mattos
2010-05-22  0:28 ` [PATCH 1/5] Documentation: alter checkout --orphan description Erick Mattos
2010-05-22  0:28 ` [PATCH 2/5] refs: split log_ref_write logic into log_ref_setup Erick Mattos
2010-05-26  5:07   ` Junio C Hamano
2010-05-26 18:11     ` Erick Mattos
2010-06-02 18:14       ` Junio C Hamano
2010-06-02 23:16         ` Erick Mattos
2010-05-22  0:28 ` [PATCH 3/5] checkout --orphan: respect -l option always Erick Mattos
2010-05-26  5:07   ` Junio C Hamano
2010-05-26 14:52     ` Erick Mattos
2010-05-26 15:13       ` Erik Faye-Lund [this message]
2010-05-26 16:01         ` Erick Mattos
2010-06-03 16:28         ` Erick Mattos
2010-05-26 15:31       ` Michael J Gruber
2010-05-26 18:04         ` Erick Mattos
2010-05-27  7:50           ` Michael J Gruber
2010-05-22  0:28 ` [PATCH 4/5] t3200: test -l with core.logAllRefUpdates options Erick Mattos
2010-05-22  0:43 ` [PATCH 5/5] bash completion: add --orphan to 'git checkout' Erick Mattos

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=AANLkTikKAkwHYj6OvfEJM1YE8w2TZL2oeMBrj28V3CwX@mail.gmail.com \
    --to=kusmabite@googlemail.com \
    --cc=erick.mattos@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kusmabite@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).