Revision 3ec804490a265f4c418a321428c12f3f18b7eff5 authored by Jeff King on 29 April 2017, 12:36:44 UTC, committed by Junio C Hamano on 05 May 2017, 03:07:27 UTC
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>
1 parent 7654286
git-cvsexportcommit.txt
git-cvsexportcommit(1)
======================
NAME
----
git-cvsexportcommit - Export a single commit to a CVS checkout
SYNOPSIS
--------
[verse]
'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot]
[-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
DESCRIPTION
-----------
Exports a commit from Git to a CVS checkout, making it easier
to merge patches from a Git repository into a CVS repository.
Specify the name of a CVS checkout using the -w switch or execute it
from the root of the CVS working copy. In the latter case GIT_DIR must
be defined. See examples below.
It does its best to do the safe thing, it will check that the files are
unchanged and up to date in the CVS checkout, and it will not autocommit
by default.
Supports file additions, removals, and commits that affect binary files.
If the commit is a merge commit, you must tell 'git cvsexportcommit' what
parent the changeset should be done against.
OPTIONS
-------
-c::
Commit automatically if the patch applied cleanly. It will not
commit if any hunks fail to apply or there were other problems.
-p::
Be pedantic (paranoid) when applying patches. Invokes patch with
--fuzz=0
-a::
Add authorship information. Adds Author line, and Committer (if
different from Author) to the message.
-d::
Set an alternative CVSROOT to use. This corresponds to the CVS
-d parameter. Usually users will not want to set this, except
if using CVS in an asymmetric fashion.
-f::
Force the merge even if the files are not up to date.
-P::
Force the parent commit, even if it is not a direct parent.
-m::
Prepend the commit message with the provided prefix.
Useful for patch series and the like.
-u::
Update affected files from CVS repository before attempting export.
-k::
Reverse CVS keyword expansion (e.g. $Revision: 1.2.3.4$
becomes $Revision$) in working CVS checkout before applying patch.
-w::
Specify the location of the CVS checkout to use for the export. This
option does not require GIT_DIR to be set before execution if the
current directory is within a Git repository. The default is the
value of 'cvsexportcommit.cvsdir'.
-W::
Tell cvsexportcommit that the current working directory is not only
a Git checkout, but also the CVS checkout. Therefore, Git will
reset the working directory to the parent commit before proceeding.
-v::
Verbose.
CONFIGURATION
-------------
cvsexportcommit.cvsdir::
The default location of the CVS checkout to use for the export.
EXAMPLES
--------
Merge one patch into CVS::
+
------------
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
$ git cvsexportcommit -v <commit-sha1>
$ cvs commit -F .msg <files>
------------
Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
+
------------
$ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
------------
Merge pending patches into CVS automatically -- only if you really know what you are doing::
+
------------
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v
------------
GIT
---
Part of the linkgit:git[1] suite
Computing file changes ...
