By limiting start revision of find_rev_before to max existing
revision. This avoids a long wait if you do
'git svn reset -r 9999999'. The linear search within the
contiguous revisions doesn't seem to be a problem.
[ew: expanded commit message]
Signed-off-by: Ben Jackson <ben@ben.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Previously there was no explicit 'help' command, but 'git svn help'
still printed the usage message (as an invalid command), provided you
got past the initialization steps that required a valid repo.
Signed-off-by: Ben Jackson <ben@ben.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
'git svn dcommit' takes an optional revision argument, but the meaning
of it was rather scary. It completely ignored the current state of
the HEAD, only looking at the revisions between SVN and $rev. If HEAD
was attached to $branch, the branch lost all commits $rev..$branch in
the process.
Considering that 'git svn dcommit HEAD^' has the intuitive meaning
"dcommit all changes on my branch except the last one", we change the
meaning of the revision argument. git-svn temporarily checks out $rev
for its work, meaning that
* if a branch is specified, that branch (_not_ the HEAD) is rebased as
part of the dcommit,
* if some other revision is specified, as in the example, all work
happens on a detached HEAD and no branch is affected.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
size_t res cannot be less than 0. fread returns 0 on error.
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the shell is not specified using the '#!' notation, then the OS will
use '/bin/sh' to execute the script which may not produce the desired
results. In particular, /bin/sh on Solaris interprets '^' specially which
has an effect on the sed command that this patch touches.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new test does a 'chmod 0', which does not have the intended
effect on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the objects that a client pushes to the server cannot be processed for
any reason, an error is reported back to the client via the git protocol.
We used to send quite detailed information if a system call failed if
unpack-objects is run. This can be regarded as an information leak. Now we
do not send any error details like we already do in the case where
index-pack failed.
Errors in system calls as well as the exit code of unpack-objects and
index-pack are now reported to stderr; in the case of a local push or via
ssh these messages still go to the client, but that is OK since these forms
of access to the server assume that the client can be trusted. If
receive-pack is run from git-daemon, then the daemon should put the error
messages into the syslog.
With this reasoning a new status report is added for the post-update-hook;
untrusted (i.e. daemon's) clients cannot observe its status anyway, others
may want to know failure details.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
That is what the documentation says, but the code pretends as if all the
known whitespace error tokens were given.
Among the whitespace error tokens, there is one kind that loosens the rule
when set: cr-at-eol. Which means that whitespace error token that is set
to true ignores a newly introduced CR at the end, which is inconsistent
with the documentation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a CR is accidentally added at the end of a C source file in the git
project tree, "git diff --check" doesn't detect it as an error.
$ echo abQ | tr Q '\015' >>fast-import.c
$ git diff --check
I think this is because the "whitespace" attribute is set to *.[ch] files
without specifying what kind of errors are caught. It makes git "notice
all types of errors" (as described in the documentation), but I think it
is incorrectly setting cr-at-eol, too, and hides this error.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test wanted to make sure that cherry-pick exits with status 1,
but with the way it was placed after "git checkout master &&" meant
that it could have misjudged success if checkout barfed with the
same failure status.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also make the docs more consistent with the usage message. While we're
here remove the zero initializers from the static variables as they're
unnecessary.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.2:
git-show-ref.txt: remove word and make consistent
git-svn documentation: fix typo in 'rebase vs. pull/merge' section
use xstrdup, not strdup in ll-merge.c
* maint-1.6.1:
git-show-ref.txt: remove word and make consistent
git-svn documentation: fix typo in 'rebase vs. pull/merge' section
use xstrdup, not strdup in ll-merge.c
* maint-1.6.0:
git-show-ref.txt: remove word and make consistent
git-svn documentation: fix typo in 'rebase vs. pull/merge' section
use xstrdup, not strdup in ll-merge.c
Under is better than in because of the nested nature of the .git
directory.
"also using" sounds a little odd, plus we say combined with later on so
just use that.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a few remaining ones, but this fixes the trivial ones. It boils
down to two main issues that sparse complains about:
- warning: Using plain integer as NULL pointer
Sparse doesn't like you using '0' instead of 'NULL'. For various good
reasons, not the least of which is just the visual confusion. A NULL
pointer is not an integer, and that whole "0 works as NULL" is a
historical accident and not very pretty.
A few of these remain: zlib is a total mess, and Z_NULL is just a 0.
I didn't touch those.
- warning: symbol 'xyz' was not declared. Should it be static?
Sparse wants to see declarations for any functions you export. A lack
of a declaration tends to mean that you should either add one, or you
should mark the function 'static' to show that it's in file scope.
A few of these remain: I only did the ones that should obviously just
be made static.
That 'wt_status_submodule_summary' one is debatable. It has a few related
flags (like 'wt_status_use_color') which _are_ declared, and are used by
builtin-commit.c. So maybe we'd like to export it at some point, but it's
not declared now, and not used outside of that file, so 'static' it is in
this patch.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is special handling in compat/regex/regex.c for the GNU compiler
to define alloca to __builtin_alloca, but the native compiler must include
alloca.h which happens when HAVE_ALLOCA_H is defined.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mg/pushurl:
avoid NULL dereference on failed malloc
builtin-remote: Make "remote -v" display push urls
builtin-remote: Show push urls as well
technical/api-remote: Describe new struct remote member pushurl
t5516: Check pushurl config setting
Allow push and fetch urls to be different
* sb/pull-rebase:
parse-remote: remove unused functions
parse-remote: support default reflist in get_remote_merge_branch
parse-remote: function to get the tracking branch to be merge
* sb/maint-1.6.0-add-config-fix:
add: allow configurations to be overriden by command line
use xstrdup, not strdup in ll-merge.c
Conflicts:
builtin-add.c
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Allow diff view without context lines
gitk: Add another string to translation
gitk: Add option 'Simple history' to the options menu
gitk: Handle msysGit version during version comparisons
gitk: Make more options easily accessible from Edit View dialog
gitk: Check git version before using --textconv flag
gitk: Use --textconv to generate diff text
gitk: Update German translation.
Don't call git_config after parsing the command line options, otherwise
the config settings will override any settings made by the command line.
This can be seen by setting add.ignore_errors and then specifying
--no-ignore-errors when using git-add.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach stash pop, apply, save, and drop to be quiet when told. By using
the quiet option (-q), these actions will be silent unless errors are
encountered.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am and git-rebase are talkative scripts. Teach them to be quiet when
told, allowing them to speak only when they fail or experience errors.
The quiet option is maintained when git-am or git-rebase fails to apply
a patch. This means subsequent --resolved, --continue, --skip, --abort
invocations will be quiet if the original invocation was quiet.
Drop a handful of >&2 redirection; the rest of the program sends all the
info messages to stdout, not to stderr.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
upload-pack runs pack-objects, which generates progress indicator output
on its stderr. If the client requests a sideband, this indicator is sent
to the client; but if it did not, then the progress is written to
upload-pack's own stderr.
If upload-pack is itself run from git-daemon (and if the client did not
request a sideband) the progress indicator never reaches the client and it
need not be generated in the first place. With this patch the progress
indicator is suppressed in this situation.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If git-daemon is run with --detach or --inetd, then stderr is explicitly
redirected to /dev/null. But notice that the service programs were spawned
via execl_git_cmd(), in particular, the stderr channel is inherited from
the daemon. This means that errors that the programs wrote to stderr (for
example, via die()), went to /dev/null.
This patch arranges that the daemon does not merely exec the service
program, but forks it and monitors stderr of the child; it writes the
errors that it produces to the daemons log via logerror().
A consequence is that the daemon process remains in memory for the full
duration of the service program, but this cannot be avoided.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a configuration option, http.sslCertPasswordProtected, and associated
environment variable, GIT_SSL_CERT_PASSWORD_PROTECTED, to enable SSL client
certificate password prompt from within git. If this option is false and
if the environment variable does not exist, git falls back to OpenSSL's
prompts (as in earlier versions of git).
The environment variable may only be used to enable, not to disable
git's password prompt. This behavior mimics GIT_NO_VERIFY; the mere
existence of the variable is all that is checked.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If an SSL client certificate is enabled (via http.sslcert or
GIT_SSL_CERT), prompt for the certificate password rather than
defaulting to OpenSSL's password prompt. This causes the prompt to only
appear once each run. Previously, OpenSSL prompted the user *many*
times, causing git to be unusable over HTTPS with client-side
certificates.
Note that the password is stored in memory in the clear while the
program is running. This may be a security problem if git crashes and
core dumps.
The user is always prompted, even if the certificate is not encrypted.
This should be fine; unencrypted certificates are rare and a security
risk anyway.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
