From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Jędrzej Dudkiewicz" <jedrzej.dudkiewicz@gmail.com>,
"Adam Dinwoodie" <adam@dinwoodie.org>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: Cannot run `git submodule init` on Cygwin from script with strict error checking
Date: Tue, 15 Sep 2020 22:31:05 +0200 [thread overview]
Message-ID: <20200915203105.GB23146@szeder.dev> (raw)
In-Reply-To: <xmqqsgbonnco.fsf@gitster.c.googlers.com>
On Fri, Sep 11, 2020 at 12:07:51PM -0700, Junio C Hamano wrote:
> SZEDER Gábor <szeder.dev@gmail.com> writes:
>
> > Having said that, unlike 'git submodule', 'git-sh-setup' is meant to
> > be dot-sourced into users' shell scripts, and, therefore, should work
> > with the shell options set in users' scripts, including even 'set -u'.
>
> Is it and should it?
>
> git-sh-setup was meant to be an implementation detail for our own
> scripts and we know don't use "-u -e". We never cared about
> backward compatibility for such use by end-users when we made any
> update to the git-sh-setup scriptlet. We freely changed existing
> features and squatted on good names for variables and functions we
> used in it, because it is designed as a private helper library.
It has a manpage that it installed by 'make install-doc', and 'man
git' advertises it, so I use it in most of my git-foo shell scripts,
e.g. for 'require_clean_work_tree'.
> Having said that, we do protect from end-user misconfiguration like
> exporting CDPATH, and protecting ourselves from exporting SHELLOPTS
> is not something I would oppose.
>
> Thanks.
prev parent reply other threads:[~2020-09-15 20:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 8:20 Cannot run `git submodule init` on Cygwin from script with strict error checking Jędrzej Dudkiewicz
2020-09-11 11:30 ` Adam Dinwoodie
2020-09-11 11:46 ` Jędrzej Dudkiewicz
2020-09-11 13:19 ` SZEDER Gábor
2020-09-11 19:07 ` Junio C Hamano
2020-09-15 20:31 ` SZEDER Gábor [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=20200915203105.GB23146@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=adam@dinwoodie.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jedrzej.dudkiewicz@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 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.