When a remote server uses git-shell, the client side will
connect to it like:
ssh server "git-upload-pack 'foo.git'"
and we literally exec ("git-upload-pack", "foo.git"). In
early versions of upload-pack and receive-pack, we took a
repository argument and nothing else. But over time they
learned to accept dashed options. If the user passes a
repository name that starts with a dash, the results are
confusing at best (we complain of a bogus option instead of
a non-existent repository) and malicious at worst (the user
can start an interactive pager via "--help").
We could pass "--" to the sub-process to make sure the
user's argument is interpreted as a branch name. I.e.:
git-upload-pack -- -foo.git
But adding "--" automatically would make us inconsistent
with a normal shell (i.e., when git-shell is not in use),
where "-foo.git" would still be an error. For that case, the
client would have to specify the "--", but they can't do so
reliably, as existing versions of git-shell do not allow
more than a single argument.
The simplest thing is to simply disallow "-" at the start of
the repo name argument. This hasn't worked either with or
without git-shell since version 1.0.0, and nobody has
complained.
Note that this patch just applies to do_generic_cmd(), which
runs upload-pack, receive-pack, and upload-archive. There
are two other types of commands that git-shell runs:
- do_cvs_cmd(), but this already restricts the argument to
be the literal string "server"
- admin-provided commands in the git-shell-commands
directory. We'll pass along arbitrary arguments there,
so these commands could have similar problems. But these
commands might actually understand dashed arguments, so
we cannot just block them here. It's up to the writer of
the commands to make sure they are safe. With great
power comes great responsibility.
Reported-by: Timo Schmid <tschmid@ernw.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Set the NO_REGEX=NeedsStartEnd Makefile flag by default on AIX.
Since commit 2f8952250a ("regex: add regexec_buf() that can work on a
non NUL-terminated string", 2016-09-21) git has errored out at
compile-time if the regular expression library doesn't support
REG_STARTEND.
While looking through Google search results for the use of NO_REGEX I
found a Chef recipe that set this on AIX[1], looking through the
documentation for the latest version of AIX (7.2, released October
2015) shows that its regexec() doesn't have REG_STARTEND.
1. https://github.com/chef/omnibus-software/commit/e247e36761#diff-3df898345d670979b74acc0bf71d8c47
2. https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.basetrf2/regexec.htm
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We forgot to prepare the submodule env, which is only a problem for
nested submodules. See 2e5d6503bd (ls-files: fix recurse-submodules
with nested submodules, 2017-04-13) for further explanation.
To come up with a proper test for this, we'd need to look at nested
submodules just as in that given commit. It turns out we're lucky
and these tests already exist, but are marked as failing. We need
to pass `--recurse-submodules` to read-tree additionally to make
these tests pass. Passing that flag alone would not make the tests
pass, such that this covers testing for the bug fix of the submodule
env as well.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All commands that are run in a submodule, are run in a correct setup,
there is no need to prepare the environment without setting the GIT_DIR
variable. By setting the GIT_DIR variable we fix issues as discussed in
10f5c52656 (submodule: avoid auto-discovery in
prepare_submodule_repo_env(), 2016-09-01)
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We do not need to declare another struct child_process, but we can just
reuse the existing `cp` struct.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git clone --config" uses the following incantation to add an item to
a config file, instead of replacing an existing value:
git_config_set_multivar_gently(key, value, "^$", 0)
As long as no existing value matches the regex ^$, that works as
intended and adds to the config. When a value is empty, though, it
replaces the existing value.
Noticed while trying to set credential.helper during a clone to use a
specific helper without inheriting from ~/.gitconfig and
/etc/gitconfig. That is, I ran
git clone -c credential.helper= \
-c credential.helper=myhelper \
https://example.com/repo
intending to produce the configuration
[credential]
helper =
helper = myhelper
Without this patch, the 'helper =' line is not included and the
credential helper from /etc/gitconfig gets used.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git's configuration system works by reading multiple configuration
files in order, from general to specific:
- first, the system configuration /etc/gitconfig
- then the user's configuration (~/.gitconfig or ~/.config/git/config)
- then the repository configuration (.git/config)
For single-valued configuration items, the latest value wins. For
multi-valued configuration items, values accumulate in that order.
For example, this allows setting a credential helper globally in
~/.gitconfig that git will try to use in all repositories, regardless
of whether they additionally provide another helper. This is usually
a nice thing --- e.g. I can install helpers to use my OS keychain and
to cache credentials for a short period of time globally.
Sometimes people want to be able to override an inherited setting.
For the credential.helper setting, this is done by setting the
configuration item to empty before giving it a new value. This is
already documented but the documentation is hard to find ---
git-config(1) says to look at gitcredentials(7) and the config
reference in gitcredentials(7) doesn't mention this issue.
Move the documentation to the config reference to make it easier to
find.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git rebase -i" failed to re-read the todo list file when the
command specified with the `exec` instruction updated it.
* sh/rebase-i-reread-todo-after-exec:
rebase -i: reread the todo list if `exec` touched it
32-bit Linux build on Travis CI uses stricter compilation options.
* ls/travis-stricter-linux32-builds:
travis-ci: set DEVELOPER knob for Linux32 build
Relaying status from Windows build by Travis CI was done with an
unsafe invocation of printf.
* ls/travis-win-fix-status:
travis-ci: printf $STATUS as string
Fix a segv in 'submodule init' when url is not given for a submodule.
* jk/submodule-init-segv-fix:
submodule_init: die cleanly on submodules without url defined
Completion for "git checkout <branch>" that auto-creates the branch
out of a remote tracking branch can now be disabled, as this
completion often gets in the way when completing to checkout an
existing local branch that happens to share the same prefix with
bunch of remote tracking branches.
* jk/complete-checkout-sans-dwim-remote:
completion: optionally disable checkout DWIM
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The building of the reflog message is using strbuf, which is not
friendly with internationalization frameworks. No other reflog
messages are translated right now and switching all the messages to
i18n would require a major rework of the way the messages are built.
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit cf9e55f494 ("submodule: prevent backslash expantion in submodule
names", 07-04-2017) added a test which creates a git repository with
some backslash characters in the name. On windows, where the backslash
character is a directory separator, it is not possible to create a
repository with the name 'sub\with\backslash'. (The NTFS filesystem would
probably allow it, but the win32 api does not). The MinGW and Git for
Windows versions of git actually create a repository called 'backslash'
in the sub-directory 'sub/with'.
On cygwin, however, due to the slightly schizophrenic treatment of the
backslash character by cygwin-git, this test fails at the 'git init'
stage. The git-init command does not recognise the directory separators
in the input path (eg. is_dir_sep('\\') is false), so it does not
attempt to create the leading directories 'sub/with'. (The call to
mkdir('sub\\with\\backslash') actually does recognise the directory
separators, but fails because the 'sub/with' directory doesn't exist).
In order to suppress the test failure (for now), add the !CYGWIN test
prerequisite.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Listing the specific hooks might feel verbose but without it the
reader is left to wonder which hooks are triggered during the
push. Something which is not immediately obvious when only trying
to find out where the hook is executed.
Signed-off-by: Simon Ruderich <simon@ruderich.org>
Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
