From: Junio C Hamano <gitster@pobox.com>
To: John Szakmeister <john@szakmeister.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] [kernel] completion: silence "fatal: Not a git repository" error
Date: Tue, 14 Oct 2014 15:14:06 -0700 [thread overview]
Message-ID: <xmqqiojmxpsh.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: CAEBDL5V_Mzxwc4fnybg9=fmeotGV91XerzTccHMWLV79bE+mVA@mail.gmail.com
John Szakmeister <john@szakmeister.net> writes:
> On Tue, Oct 14, 2014 at 2:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Hmph, do you mean this one?
>>
>> $ cd /var/tmp ;# not a git repository
>> $ git checkout <TAB>
>>
>> ->
>>
>> $ git checkout fatal: Not a git repository (or any of the parent directories): .git
>> HEAD
>>
>> I agree it is ugly, but would it be an improvement for the end user,
>> who did not realize that she was not in a directory where "git checkout"
>> makes sense, not to tell her that she is not in a git repository in
>> some way?
>
> I had thought about that too, but I think--for me--it comes down to two things:
>
> 1) We're not intentionally trying to inform the user anywhere else
> that they are not in a git repo. We simply fail to complete anything,
> which I think is an established behavior.
> 2) It mingles with the stuff already on the command line, making it
> confusing to know what you typed. Then you end up ctrl-c'ing your way
> out of it and starting over--which is the frustrating part.
It is not that I am unsympathetic. It's just it looks to me that
the patch is potentially adding one more failed step by hiding the
error message to further frustrate the user.
$ git checkout <TAB>
... completes nothing; puzzled but decides not to be worried for now
$ git checkout master<RET>
fatal: not a git repository
As you noticed, however, we do not show the ugly error message by
design. It is not done consistently, either (happens only when we
try to complete refnames).
I was just hoping that somebody (not necessarily you) could suggest
a way to do better than hide the error message only because it looks
ugly (iow, perhaps show it not in the middle of the command line,
and do so more consistently). Yes I would imagine it would be a lot
harder, but the end user experience _might_ become so much better to
make it worthwhile. I dunno.
I am not strongly opposed to queuing the patch.
prev parent reply other threads:[~2014-10-14 22:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-14 10:49 [PATCH] [kernel] completion: silence "fatal: Not a git repository" error John Szakmeister
2014-10-14 13:58 ` John Szakmeister
2014-10-14 18:29 ` Junio C Hamano
2014-10-14 19:18 ` John Szakmeister
2014-10-14 22:14 ` Junio C Hamano [this message]
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=xmqqiojmxpsh.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=john@szakmeister.net \
/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.