On Thu, May 4, 2017 at 10:26 AM, Tom Hale <tom@xxxxxxx> wrote:
>
> On 17/04/17 11:24, Junio C Hamano wrote:
>> "Tom \"Ravi\" Hale" <tom@xxxxxxx> writes:
>>
>> > If a user types `set -e` in an interactive shell, and is using __git_ps1
>> > to set
>> > their prompt, the shell will die if the current directory isn't inside a git
>> > repository.
>> >
>> Hmph. So the fix would be something like this?
>>
>> repo_info="$(git rev-parse --git-dir --is-inside-git-dir \
>> --is-bare-repository --is-inside-work-tree \
>> - --short HEAD 2>/dev/null)"
>> + --short HEAD 2>/dev/null || :)"
>
> Nope, that would cause the next line
> rev_parse_exit_code="$?"
> to always be assigned 0.
>
> I believe the patch we're after is attached.
I see how this would fix things, but this just seems like a rather
crazy thing for us to support, we can take this patch, but it's going
to take quite some maintenance burden to ensure that this code is set
-e clean going forward, and I don't think we should take a patch like
this without some general support in the regression tests to ensure
that the completion code is set -e clean, otherwise this is going to
very easily regress the next time someone not aware of this patches
it.
What's the real use-case here? If you do "set -e" in your shell you
also get e.g.:
$ ls -l blah
ls: cannot access blah: No such file or directory
=== Command terminated with exit status 2 (Thu May 4 11:16:03 2017) ===
I.e. any little failure will terminate your shell, are you actually
running a shell like this? For what purpose?