This commit fixes a bug in processing project-specific override in
a situation when there is no project, e.g. for the projects list page.
When 'snapshot' feature had project specific config override enabled
by putting
$feature{'snapshot'}{'override'} = 1;
(or equivalent) in $GITWEB_CONFIG, and when viewing toplevel gitweb
page, which means the projects list page (to be more exact this
happens for any project-less action), gitweb would put the following
Perl warnings in error log:
gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2065.
fatal: error processing config file(s)
gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2221.
gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2218.
The problem is in the following fragment of code:
# path to the current git repository
our $git_dir;
$git_dir = "$projectroot/$project" if $project;
# list of supported snapshot formats
our @snapshot_fmts = gitweb_get_feature('snapshot');
@snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
For the toplevel gitweb page, which is the list of projects, $project is not
defined, therefore neither is $git_dir. gitweb_get_feature() subroutine
calls git_get_project_config() if project specific override is turned
on... but we don't have project here.
Those errors mentioned above occur in the following fragment of code in
git_get_project_config():
# get config
if (!defined $config_file ||
$config_file ne "$git_dir/config") {
%config = git_parse_project_config('gitweb');
$config_file = "$git_dir/config";
}
git_parse_project_config() calls git_cmd() which has '--git-dir='.$git_dir
There are (at least) three possible solutions:
1. Harden gitweb_get_feature() so that it doesn't call
git_get_project_config() if $project (and therefore $git_dir) is not
defined; there is no project for project specific config.
2. Harden git_get_project_config() like you did in your fix, returning early
if $git_dir is not defined.
3. Harden git_cmd() so that it doesn't add "--git-dir=$git_dir" if $git_dir
is not defined, and change git_get_project_config() so that it doesn't
even try to access $git_dir if it is not defined.
This commit implements both 1.) and 2.), i.e. gitweb_get_feature() doesn't
call project-specific override if $git_dir is not defined (if there is no
project), and git_get_project_config() returns early if $git_dir is not
defined.
Add a test for this bug to t/t9500-gitweb-standalone-no-errors.sh test.
Reported-by: Eli Barzilay <eli@barzilay.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move non-fast forward tests to lib-httpd.sh so that we don't have to
duplicate the tests in both t5540 and t5541.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As reported by Mark Lodato, "git bisect", when it was started with
path parameters that match no commit was kind of working without
taking account of path parameters and was reporting something like:
Bisecting: -1 revisions left to test after this (roughly 0 steps)
It is more correct and safer to just error out in this case, before
displaying the revisions left, so this patch does just that.
Note that this bug is very old, it exists at least since v1.5.5.
And it is possible to detect that case earlier in the bisect
algorithm, but it is not clear that it would be an improvement to
error out earlier, on the contrary it may change the behavior of
"git rev-list --bisect-all" for example, which is currently correct.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add tests for git-am using files with DOS line endings for various
combinations of `--keep-cr`, `--no-keep-cr` and `am.keepcr`.
Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Verify that the output format is correct for successful, rejected, and
flagrantly erroneous pushes.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, if gc.reflogexpire or gc.reflogexpire were set to "never"
or "false", the builtin default values were used instead.
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, prune treated an expiration time of 0 to mean that no
expire argument was supplied, and everything should be pruned. As a
result, "prune --expire=never" would prune all unreachable objects,
regardless of their timestamp.
prune can be called with --expire=never automatically by gc, when the
gc.pruneExpire configuration is set to "never".
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If parent J is an ancestor of parent I, then parent J should be
discarded, not I.
Note that J is an ancestor of I if and only if rev-list I..J is emtpy,
which is what we are testing here.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
When svn:mergeinfo contains two new parents in a specific order and
one is ancestor of the other, it is possible that git-svn discards the
wrong one. The first test case ("commit made to merged branch is
reachable from the merge") proves this.
The second test case ("merging two branches in one commit is detected
correctly") is just for completeness, since there was no test for
merging two (feature) branches to trunk in one commit.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
A few "svn cp" commands and commit commands were executed in incorrect
order. Therefore some of the desired commits were missing and some
were committed with wrong revision number in the commit message. This
made it hard to compare the produced git repository with the SVN
repository.
The dump file is updated too, but only the relevant parts and with
hand-edited timestamps to make history linear.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Requires a small change to wrap-for-bin.sh in order to work.
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, the equivalent of "/dev/null" is "nul". This implements
compatibility wrappers around fopen() and freopen() that check for this
particular file name.
The new tests exercise code paths where this is relevant.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is required on Windows because git-notes is now a built-in
rather than a shell script.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since "git fetch" learned "--all" and "--multiple" options, it has become
tempting for users to say "git pull --all". Even though it may fetch from
remotes that do not need to be fetched from for merging with the current
branch, it is handy.
"git fetch" however clears the list of fetched branches every time it
contacts a different remote. Unless the current branch is configured to
merge with a branch from a remote that happens to be the last in the list
of remotes that are contacted, "git pull" that fetches from multiple
remotes will not be able to find the branch it should be merging with.
Make "fetch" clear FETCH_HEAD (unless --append is given) and then append
the list of branches fetched to it (even when --append is not given). That
way, "pull" will be able to find the data for the branch being merged in
FETCH_HEAD no matter where the remote appears in the list of remotes to be
contacted by "git fetch".
Reported-by: Michael Lukashov
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running a subfetch, the code propagated some options but not others.
Propagate --force, --update-head-ok and --keep options as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All of these tests were bogus, as they created new directory and tried to
run "git pull" without even running "git init" in there. They were mucking
with the repository in $TEST_DIRECTORY.
While fixing it, modernize the style not to chdir around outside of
subshell. Otherwise a failed test will take us to an unexpected directory
and we need to chdir back to the test directory in each test, which is
ugly and error prone.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we look at a patch for adding hunks interactively, we
first split it into a header and a list of hunks. Some of
the header lines, such as mode changes and deletion, however,
become their own selectable hunks. Later when we reassemble
the patch, we simply concatenate the header and the selected
hunks. This leads to patches like this:
diff --git a/file b/file
index d95f3ad..0000000
--- a/file
+++ /dev/null
deleted file mode 100644
@@ -1 +0,0 @@
-content
Notice how the deletion comes _after_ the ---/+++ lines,
when it should come before.
In many cases, we can get away with this as git-apply
accepts the slightly bogus input. However, in the specific
case of a deletion line that is being applied via "apply
-R", this malformed patch triggers an assert in git-apply.
This comes up when discarding a deletion via "git checkout
-p".
Rather than try to make git-apply accept our odd input,
let's just reassemble the patch in the correct order.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to unnecessarily give the read permission to group and others,
regardless of the umask, which isn't serious because the objects are
still protected by their containing directory, but isn't necessary
either.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to create 0600 files, and then use chmod to set the group and
other permission bits to the umask. This usually has the same effect
as a normal file creation with a umask.
But in the presence of ACLs, the group permission plays the role of
the ACL mask: the "g" bits of newly created files are chosen according
to default ACL mask of the directory, not according to the umask, and
doing a chmod() on these "g" bits affect the ACL's mask instead of
actual group permission.
In other words, creating files with 0600 and then doing a chmod to the
umask creates files which are unreadable by users allowed in the
default ACL. To create the files without breaking ACLs, we let the
umask do it's job at the file's creation time, and get rid of the
later chmod.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right now, Git creates unreadable pack files on non-shared
repositories when the user has a umask of 077, even when the default
ACLs for the directory would give read/write access to a specific
user.
Loose object files are created world-readable, which doesn't break ACLs,
but isn't necessarily desirable.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pagers that do not consume their input are dangerous: for example,
$ GIT_PAGER=: git log
$ echo $?
141
$
The only reason these tests were able to work before was that
'git log' would write to the pipe (and not fill it) before the
pager had time to terminate and close the pipe.
Fix it by using a program that consumes its input, namely wc (as
suggested by Johannes).
Reported-by: Johannes Sixt <j.sixt@viscovery.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds two test cases for:
6977c25 git diff --quiet -w: check and report the status
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sp/push-sideband:
receive-pack: Send internal errors over side-band #2
t5401: Use a bare repository for the remote peer
receive-pack: Send hook output over side band #2
receive-pack: Wrap status reports inside side-band-64k
receive-pack: Refactor how capabilities are shown to the client
send-pack: demultiplex a sideband stream with status data
run-command: support custom fd-set in async
run-command: Allow stderr to be a caller supplied pipe
Testing pagination requires (fake or real) access to a terminal so we
can see whether the pagination automatically kicks in, which makes it
hard to get good coverage when running tests without --verbose. There
are a number of ways to work around that:
- Replace all isatty calls with calls to a custom xisatty wrapper
that usually checks for a terminal but can be overridden for tests.
This would be workable, but it would require implementing xisatty
separately in three languages (C, shell, and perl) and making sure
that any code that is to be tested always uses the wrapper.
- Redirect stdout to /dev/tty. This would be problematic because
there might be no terminal available, and even if a terminal is
available, it might not be appropriate to spew output to it.
- Create a new pseudo-terminal on the fly and capture its output.
This patch implements the third approach.
The new test-terminal.perl helper uses IO::Pty from Expect.pm to create
a terminal and executes the program specified by its arguments with
that terminal as stdout. If the IO::Pty module is missing or not
working on a system, the test script will maintain its old behavior
(skipping most of its tests unless GIT_TEST_OPTS includes --verbose).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-p4: fix bug in symlink handling
t1450: fix testcases that were wrongly expecting failure
Documentation: Fix indentation problem in git-commit(1)
Git’s automatic pagination support has some subtleties. Add some
tests to make sure we don’t break:
- when git will use a pager by default;
- the effect of the --paginate and --no-pager options;
- the effect of pagination on use of color;
- how the choice of pager is configured.
This does not yet test:
- use of pager by scripted commands (git svn and git am);
- effect of the pager.* configuration variables;
- setting of the LESS variable.
Some features involve checking whether stdout is a terminal, so many
of these tests are skipped unless output is passed through to the
terminal (i.e., unless $GIT_TEST_OPTS includes --verbose).
The immediate purpose for these tests was to avoid making things worse
after the breakage from my jn/editor-pager series (see commit 376f39,
2009-11-20). Thanks to Sebastian Celis <sebastian@sebastiancelis.com>
for the report.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Almost exactly a year ago in 02a6552 (Test fsck a bit harder), I
introduced two testcases that were expecting failure.
However, the only bug was that the testcases wrote *blobs* because I
forgot to pass -t tag to hash-object. Fix this, and then adjust the
rest of the test to properly check the result.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we remove a path in a/deep/subdirectory, we should try to
remove as many trailing components as possible (i.e.,
subdirectory, then deep, then a). However, the test for the
return value of rmdir was reversed, so we only ever deleted
at most one level.
The fix is in remove_path, so "apply" and "merge-recursive"
also are fixed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When invoking "git submodule summary" in an empty repo (which can be
indirectly done by setting status.submodulesummary = true), it currently
emits an error message (via "git diff-index") since HEAD points to an
unborn branch.
This patch adds handling of the HEAD-points-to-unborn-branch special case,
so that "git submodule summary" no longer emits this error message.
The patch also adds a test case that verifies the fix.
Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a test for 'git add -u pathspec' and 'git add pathspec' where
pathspec does not exist. The expected result is that git add exits with
an error message and an appropriate exit code.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Prepare 1.7.0.1 release notes
Fix use of mutex in threaded grep
dwim_ref: fix dangling symref warning
stash pop: remove 'apply' options during 'drop' invocation
diff: make sure --output=/bad/path is caught
Remove hyphen from "git-command" in two error messages
* maint-1.6.6:
dwim_ref: fix dangling symref warning
stash pop: remove 'apply' options during 'drop' invocation
diff: make sure --output=/bad/path is caught
Remove hyphen from "git-command" in two error messages
This kind of test requires a throw-away root filesystem so that it can
play on. If you have such a system, go ahead, "chmod 777 /" and run
this test manually. Because this is a dangerous test, you are required
to set an env variable, and not to use root to run it.
Script prepare-root.sh may help you set up a chroot environment with
Git test suite inside. You will need Linux, static linked busybox,
rsync and root permission to use it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'git stash pop' option parsing used to remove the first argument
in --index mode. At the time this was implemented, this first
argument was always --index. However, since the invention of the -q
option in fcdd0e9 (stash: teach quiet option, 2009-06-17) you can
cause an internal invocation of
git stash drop --index
by running
git stash pop -q --index
which then of course fails because drop doesn't know --index.
To handle this, instead let 'git stash apply' decide what the future
argument to 'drop' should be.
Warning: this means that 'git stash apply' must parse all options that
'drop' can take, and deal with them in the same way. This is
currently true for its only option -q.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is useful for keeping notes to objects that are being rewritten by e.g.
'git commit --amend', 'git rebase', or 'git cherry-pick'.
"git notes copy <from> <to>" is in practice equivalent to
"git notes add -C $(git notes list <from>) <to>", although it is somewhat
more convenient for regular users.
"git notes copy" takes the same -f option as "git add", to overwrite existing
notes at the target (instead of aborting with an error message).
If the <from>-object has no notes, "git notes copy" will abort with an error
message.
The patch includes tests verifying correct behaviour of the new subcommand.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Inspired by the -c/-C options to "git commit", we teach these options to
"git notes add/append" to allow reuse of note objects.
With this patch in place, it is now easy to copy or move notes between
objects. For example, to copy object A's notes to object B:
git notes add [-f] -C $(git notes list A) B
To move instead of copying, you simply remove the notes from the source
object afterwards, e.g.:
git notes remove A
The patch includes tests verifying correct behaviour of the new functionality.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By moving the -F option handling into a separate function (parse_file_arg),
we can start allowing several -F options, and mixed usage of -m and -F
options. Each -m/-F given appends to the note message, in the order they are
given on the command-line.
The patch includes tests verifying correct behaviour of the new functionality.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The semantics for "git notes edit -m/-F" overlap with those for
"git notes add -f", and the behaviour (i.e. overwriting existing
notes with the given message/file) is more intuitively captured
by (and better documented with) "git notes add -f".
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git notes append" is equivalent to "git notes edit" except that instead
of editing existing notes contents, you can only append to it. This is
useful for quickly adding annotations like e.g.:
git notes append -m "Acked-by: A U Thor <author@example.com>"
"git notes append" takes the same -m/-F options as "git notes add".
If there is no existing note to append to, "git notes append" is identical
to "git notes add" (i.e. it adds a new note).
The patch includes tests verifying correct behaviour of the new subcommand.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git notes add" is identical to "git notes edit" except that instead of
editing existing notes for a given object, you can only add notes to an
object that currently has none. If "git notes add" finds existing notes
for the given object, the addition is aborted. However, if the new
-f/--force option is used, "git notes add" will _overwrite_ the existing
notes with the new notes contents.
If there is no existing notes for the given object. "git notes add" is
identical to "git notes edit" (i.e. it adds a new note).
The patch includes tests verifying correct behaviour of the new subcommand.
Suggested-by: Joey Hess <joey@kitenet.net>
Improved-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git notes list" will list all note objects in the current notes ref (in the
format "<note object> <annotated object>"). "git notes list <object>" will
list the note object associated with the given <object>, or fail loudly if
the given <object> has no associated notes.
If no arguments are given to "git notes", it defaults to the "list"
subcommand. This is for pseudo-compatibility with "git tag" and "git branch".
The patch includes tests verifying correct behaviour of the new subcommand.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git notes prune" will remove all notes that annotate unreachable/non-
existing objects.
The patch includes tests verifying correct behaviour of the new subcommand.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using "git notes remove" is equivalent to specifying an empty note message.
The patch includes tests verifying correct behaviour of the new subcommand.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the result of editing a note is an empty string, the associated note
entry should be deleted from the notes tree.
This allows deleting notes by invoking either "git notes -m ''" or
"git notes -F /dev/null".
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The note tree structure allows for non-note entries to coexist with note
entries in a notes tree. Although we certainly expect there to be very
few non-notes in a notes tree, we should still support them to a certain
degree.
This patch teaches the notes code to preserve non-notes when updating the
notes tree with write_notes_tree(). Non-notes are not affected by fanout
restructuring.
For non-notes to be handled correctly, we can no longer allow subtree
entries that do not match the fanout structure produced by the notes code
itself. This means that fanouts like 4/36, 6/34, 8/32, 4/4/32, etc. are
no longer recognized as note subtrees; only 2-based fanouts are allowed
(2/38, 2/2/36, 2/2/2/34, etc.). Since the notes code has never at any point
_produced_ non-2-based fanouts, it is highly unlikely that this change will
cause problems for anyone.
The patch also adds some tests verifying the correct handling of non-notes
in a notes tree.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a test verifying that the notes code automatically restructures the
notes tree into a deeper fanout level, when many notes are added with
"git notes".
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adds a testcase verifying that git-notes works successfully on
tree, blob, and tag objects.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The builtin-ification includes some minor behavioural changes to the
command-line interface: It is no longer allowed to mix the -m and -F
arguments, and it is not allowed to use multiple -F options.
As part of the builtin-ification, we add the commit_notes() function
to the builtin API. This function (together with the notes.h API) can
be easily used from other builtins to manipulate the notes tree.
Also includes needed changes to t3301.
This patch has been improved by the following contributions:
- Stephen Boyd: Use die() instead of fprintf(stderr, ...) followed by exit(1)
Cc: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Shell reports exit status only from the most downstream command
in a pipeline. In these tests, we want to make sure that the
command fails in a controlled way, and produces a correct error
message.
This issue was known by Jay who submitted the patch, and also was
pointed out by Hannes during the review process, but I forgot to
fix it up before applying. Sorry about that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-reflog-bad-timestamp:
t0101: use a fixed timestamp when searching in the reflog
Update @{bogus.timestamp} fix not to die()
approxidate_careful() reports errorneous date string
* sp/maint-push-sideband:
receive-pack: Send internal errors over side-band #2
t5401: Use a bare repository for the remote peer
Conflicts:
builtin-receive-pack.c
t/t5401-update-hooks.sh
If the client has requested side-band-64k capability, send any
of the internal error or warning messages in the muxed side-band
stream using the same band as our hook output, band #2. By putting
everything in one stream we ensure all messages are processed by
the side-band demuxer, avoiding interleaving between our own stderr
and the side-band demuxer's stderr buffers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We want to avoid the warnings (or later, test failures) about
updating the current branch. It was never my intention to have
this test deal with a repository with a working directory, and it
is a very old bug that the test even used a non-bare repository
for the remote side of the push operations.
This fixes the interleaved output error we were seeing as a test
failure by avoiding the giant warning message we were getting back
about updating the current branch being risky.
Its not a real fix, but is something we should do no matter what,
because the behavior will change in the future to reject, and the
test would break at that time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
8424981: "Fix invalid read in quote_c_style_counted" introduced a test
that used "caractère spécial" as a directory name.
Git creates it as "caract\303\250re sp\303\251cial"
OS X stores it as "caracte\314\200re spe\314\201cial"
To work around this problem, use the already introduced $FN as the
directory name.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
blame: prevent a segv when -L given start > EOF
git-push: document all the status flags used in the output
Fix parsing of imap.preformattedHTML and imap.sslverify
git-add documentation: Fix shell quoting example
blame would segv if given -L <lineno> with <lineno> past the end of the file.
While we're fixing the bug, add test cases for an invalid <start> when called
as -L <start>,<end> or -L<start>.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts most of commit a2430dde8c.
That commit made the situation better for repositories with relatively
small number of objects. However with many objects and a small pack size
limit, the time required to complete the repack tends towards O(n^2),
or even much worse with long delta chains.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently the only way to "quote" a grep pattern that might
begin with a dash is to use "git grep -e pattern". This
works just fine, and is also the way right way to do it on
many traditional grep implemenations.
Some people prefer to use "git grep -- pattern", however, as
"--" is the usual "end of options" marker, and at least GNU
grep and Solaris 10 grep support this. This patch makes that
syntax work.
There is a slight behavior change, in that "git grep -- $X"
used to be interpreted as "grep for -- in $X". However, that
usage is questionable. "--" is usually the end-of-options
marker, so "git grep" was unlike many other greps in
treating it as a literal pattern (e.g., both GNU grep and
Solaris 10 grep will treat "grep --" as missing a pattern).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code to guess an output archive's format consumed any --format
options and built a new one. Jonathan noticed that it does so in an
unsafe way, risking to overflow the static buffer fmt_opt.
Change the code to keep the existing --format options intact and to only
add a new one if a format could be guessed based on the output file name.
The new option is added as the first one, allowing the existing ones to
overrule it, i.e. explicit --format options given on the command line win
over format guesses, as before.
To simplify the code further, format_from_name() is changed to return the
full --format option, thus no potentially dangerous sprintf() calls are
needed any more.
Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option causes the creation or updating of a file mapping CVS
(filename, revision number) pairs to Git commit IDs. This is expected
to be useful if you have CVS revision numbers stored in commit messages,
bug-tracking systems, email archives, and the like.
Signed-off-by: Aaron Crane <git@aaroncrane.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function did not work on strings that were not NUL-terminated. It
reads through a length-bounded string, searching for characters in need of
quoting. After we find one, we output the quoted character, then advance
our pointer to find the next one. However, we never decremented the
length, meaning we ended up looking at whatever random junk was stored
after the string.
This bug was not found by the existing tests because most code paths feed
a NUL-terminated string. The notable exception is a directory name being
fed by ls-tree.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revert the previous attempt to skip this test on platforms where we
currently cannot determine the system load. We want to make sure that
the max-load-limit codepath produces results cleanly, when gitweb is
updated and becomes capable of reading the load average by some other
method.
The code to check for load returns 0 if it doesn't know how to find
load. It also checks to see if the current load is higher than the
max load. So to force the script to quit early by setting the maxload
variable negative which should work for systems where we can detect
load (which should be a positive number) and systems where we can't
(where detected load is 0)
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently gitweb only knows how to check for load using /proc/loadavg,
which isn't available on all systems. We shouldn't fail the test just
because we don't know how to check the system load.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sp/maint-push-sideband:
receive-pack: Send hook output over side band #2
receive-pack: Wrap status reports inside side-band-64k
receive-pack: Refactor how capabilities are shown to the client
send-pack: demultiplex a sideband stream with status data
run-command: support custom fd-set in async
run-command: Allow stderr to be a caller supplied pipe
Update git fsck --full short description to mention packs
Conflicts:
run-command.c
If the client requests to enable side-band-64k capability we can
safely send any hook stdout or stderr data down side band #2,
so the client can present it to the user.
If side-band-64k isn't enabled, hooks continue to inherit stderr
from the parent receive-pack process.
When the side band channel is being used the push client will wind up
prefixing all server messages with "remote: ", just like fetch does,
so our test vector has to be updated with the new expected output.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems that we have bad interaction with the code related to
GIT_WORK_TREE and "grep --no-index", and broke running grep inside
the .git directory. For now, just revert it and resurrect it after
1.7.0 ships.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The value passed to --max-pack-size used to count in MiB which was
inconsistent with the corresponding configuration variable as well as
other command arguments which are defined to count in bytes with an
optional unit suffix. This brings --max-pack-size in line with the
rest of Git.
Also, in order not to cause havoc with people used to the previous
megabyte scale, and because this is a sane thing to do anyway, a
minimum size of 1 MiB is enforced to avoid an explosion of pack files.
Adjust and extend test suite accordingly.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
First of all, trying to run 'git verify-pack' on packs produced by
the tests using pack.packSizeLimit always failed. After lots of digging
and head scratching, it turns out that the preceeding test simulating
a SHA1 collision did leave the repository quite confused, impacting
subsequent tests.
So let's move that destructive test last, and add tests to run
verify-pack on the output from those packSizeLimit tests to catch such
goofage.
Finally, group those packSizeLimit tests together.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ms/filter-branch-submodule:
filter-branch: Add tests for submodules in tree-filter
filter-branch: Fix to allow replacing submodules with another content
* 'jh/gitweb-caching' (early part):
gitweb: Add optional extra parameter to die_error, for extended explanation
gitweb: add a "string" variant of print_sort_th
gitweb: add a "string" variant of print_local_time
gitweb: Check that $site_header etc. are defined before using them
gitweb: Makefile improvements
gitweb: Load checking
gitweb: Make running t9501 test with '--debug' reliable and usable
* sp/maint-fast-import-large-blob:
fast-import: Stream very large blobs directly to pack
bash: don't offer remote transport helpers as subcommands
Conflicts:
fast-import.c
If a blob is larger than the configured big-file-threshold, instead
of reading it into a single buffer obtained from malloc, stream it
onto the end of the current pack file. Streaming the larger objects
into the pack avoids the 4+ GiB memory footprint that occurs when
fast-import is processing 2+ GiB blobs.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the same sprit as 4848509 (Fix permissions on test scripts,
2007-04-13), t/lib-patch-mode.sh should not be executable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* commit 'b319ef7': (8132 commits)
Add a small patch-mode testing library
git-apply--interactive: Refactor patch mode code
t8005: Nobody writes Russian in shift_jis
Fix severe breakage in "git-apply --whitespace=fix"
Update release notes for 1.6.4
After renaming a section, print any trailing variable definitions
Make section_name_match start on '[', and return the length on success
send-email: detect cycles in alias expansion
Show the presence of untracked files in the bash prompt.
SunOS grep does not understand -C<n> nor -e
Fix export_marks() error handling.
git repack: keep commits hidden by a graft
Add a test showing that 'git repack' throws away grafted-away parents
git branch: clean up detached branch handling
git branch: avoid unnecessary object lookups
git branch: fix performance problem
git svn: fix shallow clone when upstream revision is too new
do_one_ref(): null_sha1 check is not about broken ref
configure.ac: properly unset NEEDS_SSL_WITH_CRYPTO when sha1 func is missing
janitor: useless checks before free
...
4848509 (Fix permissions on test scripts, 2007-04-13) forgot to make
this included file non-executable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This changes slightly the behavior of gitweb, so that it verifies
that the box isn't inundated with before attempting to serve gitweb.
If the box is overloaded, it basically returns a 503 Server Unavailable
until the load falls below the defined threshold. This helps dramatically
if you have a box that's I/O bound, reaches a certain load and you
don't want gitweb, the I/O hog that it is, increasing the pain the
server is already undergoing.
This behavior is controlled by $maxload configuration variable.
Default is a load of 300, which for most cases should never be hit.
Unset it (set it to undefined value, i.e. undef) to turn off checking.
Currently it requires that '/proc/loadavg' file exists, otherwise the
load check is bypassed (load is taken to be 0). So platforms that do
not implement '/proc/loadavg' currently cannot use this feature
(provisions are included for additional checks to be added by others).
There is simple test in t/t9501-gitweb-standalone-http-status.sh to
check that it correctly returns "503 Service Unavailable" if load is
too high, and also if there are any Perl warnings or errors.
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove test_debug lines after 'snapshots: tgz only default format
enabled' and 'snapshots: all enabled in default, use default disabled
value' tests. Those tests constitute of multiple gitweb_run
invocation, therefore outputting gitweb.output for the last gitweb_run
wouldn't help much in debugging test failure, and can only confuse.
For snapshot tests which check for "200 OK" status, change
test_debug 'cat gitweb.output'
to
test_debug 'cat gitweb.headers'
Otherwise when running this test with '--debug' option,
t/t9501-gitweb-standalone-http-status.sh would dump *binary data* (the
snapshot itself) to standard output, which can mess up state of terminal
due to term control characters which can be embedded in output.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old "advice" message explained how to create a branch after going into
a detached HEAD state but didn't make it clear why the user may want to do
so. Also "moving to ... which isn't a local branch" was unclear if it is
complaining, if it is describing the new state, or if it is explaining why
the HEAD is detached (the true reason is the last one).
Give the established phrase 'detached HEAD' first to make it easy for
users to look up the concept in documentation, and briefly describe what
can be done in the state (i.e. play around without having to clean up)
before telling the user how to keep what was done during the temporary
state.
Allow the long description to be hidden by setting advice.detachedHead
configuration to false.
We might want to customize the advice depending on how the commit to check
out was spelled (e.g. instead of "new-branch-name", we way want to say
"topic" when "git checkout origin/topic" triggered this message) in later
updates, but this encapsulates that into a separate function and it should
be a good first step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add tests to make sure that:
1) a submodule can be removed and its content replaced with regular files
('rewrite submodule with another content'). This test passes only with
the previous patch applied.
2) it is possible to replace submodule revision by direct index
manipulation ('replace submodule revision'). Although it would be
better to run such a filter in --index-filter, this test shows that
this functionality is not broken by the previous patch. This succeeds
both with and without the previous patch.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Something like foo@{-1} is nonsensical, as the @{-N} syntax
is reserved for "the Nth last branch", and is not an actual
reflog selector. We should not feed such nonsense to
approxidate at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously interpret_branch_name would see @{-1} and stop
parsing, leaving the @{u} as cruft that provoked an error.
Instead, we should recurse if there is more to parse.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that we have several different types of @{} syntax, it
is a good idea to test them together, which reveals some
failures.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original version used relative approxidates, which don't
reproduce as reliably as absolute ones. Commit 6c647a fixed
this for one case, but missed the "silly" case.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"diff --cc" output t4038 tests was fixed by b810cbb (diff --cc: a lost
line at the beginning of the file is shown incorrectly, 2009-07-22), which
was actually the commit that introduced this test..
An error in "git merge -s resolve" t6035 tests was fixed by 730f728
(unpack-trees.c: look ahead in the index, 2009-09-20).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-reflog-bad-timestamp:
t0101: use a fixed timestamp when searching in the reflog
Update @{bogus.timestamp} fix not to die()
approxidate_careful() reports errorneous date string
* jl/diff-submodule-ignore:
Teach diff --submodule that modified submodule directory is dirty
git diff: Don't test submodule dirtiness with --ignore-submodules
Make ce_uptodate() trustworthy again
Using a dollar sign in double quotes isn't portable. Escape them with
a backslash or replace the double quotes with single quotes.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For a long time, the time based reflog syntax (e.g. master@{yesterday})
didn't complain when the "human readable" timestamp was misspelled, as
the underlying mechanism tried to be as lenient as possible. The funny
thing was that parsing of "@{now}" even relied on the fact that anything
not recognized by the machinery returned the current timestamp.
Introduce approxidate_careful() that takes an optional pointer to an
integer, that gets assigned 1 when the input does not make sense as a
timestamp.
As I am too lazy to fix all the callers that use approxidate(), most of
the callers do not take advantage of the error checking, but convert the
code to parse reflog to use it as a demonstration.
Tests are mostly from Jeff King.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When your current directory is not at the root of the working tree, and you
use the "-f" option with a relative path, the current code tries to read
from a wrong file, since argv[2] is now beyond the end of the rearranged
argument list.
This patch replaces the incorrect argv[2] with the variable holding the
given config file name.
The bug was introduced by d64ec16 (git config: reorganize to use parseopt).
[jc: added test]
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Historically, any grep filter in "git log" family of commands were taken
as restricting to commits with any of the words in the commit log message.
However, the user almost always want to find commits "done by this person
on that topic". With "--all-match" option, a series of grep patterns can
be turned into a requirement that all of them must produce a match, but
that makes it impossible to ask for "done by me, on either this or that"
with:
log --author=me --committer=him --grep=this --grep=that
because it will require both "this" and "that" to appear.
Change the "header" parser of grep library to treat the headers specially,
and parse it as:
(all-match-OR (HEADER-AUTHOR me)
(HEADER-COMMITTER him)
(OR
(PATTERN this)
(PATTERN that) ) )
Even though the "log" command line parser doesn't give direct access to
the extended grep syntax to group terms with parentheses, this change will
cover the majority of the case the users would want.
This incidentally revealed that one test in t7002 was bogus. It ran:
log --author=Thor --grep=Thu --format='%s'
and expected (wrongly) "Thu" to match "Thursday" in the author/committer
date, but that would never match, as the timestamp in raw commit buffer
does not have the name of the day-of-the-week.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The patch detection wants to inspect all the headers of a rfc2822 message
and ensure that they look like header fields. The headers are always
separated from the message body with a blank line. When Thunderbird saves
the message the blank line separating the headers from the body includes a
CR. The patch detection is failing because a CRLF doesn't match /^$/. Fix
this by allowing a CR to exist on the separating line.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We shouldn't have literal CR's in tests as they aren't portable.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
append_cr(), remove_cr(), q_to_nul() and q_to_cr() are defined in multiple
tests. Consolidate them into test-lib.sh so we can stop redefining them.
The use of remove_cr() in t0020 to test for a CR is replaced with a new
function has_cr() to accurately reflect what is intended (the output of
remove_cr() was being thrown away).
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't feed a multiple-line pattern to grep and expect the them to match
with lines in order.
Simplify the grep expressions in the non-fast-forward tests to check
only for the first line of the non-fast-forward warning - having that
line should be enough assurance that the full warning is printed.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit 8e08b4 git diff does append "-dirty" to the work tree side
if the working directory of a submodule contains new or modified files.
Lets do the same when the --submodule option is used.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This shows that with the "--keep" option, changes that are both in
the work tree and the index are kept in the work tree after the
reset (but discarded in the index).
In the case of unmerged entries, we can see that "git reset --keep"
works only when the target state is the same as HEAD. And then the
work tree is not reset.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/fix-tree-walk:
read-tree --debug-unpack
unpack-trees.c: look ahead in the index
unpack-trees.c: prepare for looking ahead in the index
Aggressive three-way merge: fix D/F case
traverse_trees(): handle D/F conflict case sanely
more D/F conflict tests
tests: move convenience regexp to match object names to test-lib.sh
Conflicts:
builtin-read-tree.c
unpack-trees.c
unpack-trees.h
14e5d40 (pull: Fix parsing of -X<option>, 2010-01-17) forgot that
merge_name needs to stay as a single non-interpolated string.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
git-svn: allow subset of branches/tags to be specified in glob spec
git-svn: allow UUID to be manually remapped via rewriteUUID
git-svn: update svn mergeinfo test suite
git-svn: document --username/commit-url for branch/tag
git-svn: add --username/commit-url options for branch/tag
git-svn: respect commiturl option for branch/tag
git-svn: fix mismatched src/dst errors for branch/tag
git-svn: handle merge-base failures
git-svn: ignore changeless commits when checking for a cherry-pick
For very large projects it is useful to be able to clone a subset of the
upstream SVN repo's branches. Allow for this by letting the left-side of
the branches and tags glob specs contain a brace-delineated comma-separated
list of names. e.g.:
branches = branches/{red,green}/src:refs/remotes/branches/*
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
In certain situations it may be necessary to manually remap an svn
repostitory UUID. For example:
o--- [git-svn clone]
/
[origin svn repo]
\
o--- [svnsync clone]
Imagine that only "git-svn clone" and "svnsync clone" are made available
to external users. Furthur, "git-svn clone" contains only trunk, and for
reasons unknown, "svnsync clone" is missing the revision properties that
normally provide the origin svn repo's UUID.
A git user who has cloned the "git-svn clone" repo now wishes to use
git-svn to pull in the missing branches from the "synsync clone" repo.
In order for git-svn to get the history correct for those branches,
it needs to know the origin svn repo's UUID. Hence rewriteUUID.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Add a partial branch (e.g., a branch from a project subdirectory) to the
git-svn mergeinfo test repository.
Add a tag and a branch from that tag to the git-svn mergeinfo test repository.
Update the test script to expect a known failure in git-svn exposed by these
additions where merge info for partial branches is not preserved.
Signed-off-by: Andrew Myrick <amyrick@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
4cacc621 made difftool fall back to mergetool.prompt
when difftool.prompt is unconfigured. This adds a test.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jl/submodule-diff:
Performance optimization for detection of modified submodules
git status: Show uncommitted submodule changes too when enabled
Teach diff that modified submodule directory is dirty
Show submodules as modified when they contain a dirty work tree
The function takes two paths, an early part of abs is supposed to match
base; otherwise abs is not a path under base and the function returns the
full path of abs. The caller can easily confuse the implementation by
giving duplicated and needless slashes in these path arguments.
Credit for test script, motivation and initial patch goes to Thomas Rast.
A follow-up fix (squashed) is by Hannes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code used as if return value from basename(3) were stable, but
often the function is implemented to return a pointer to a static
storage internal to it.
Because basename(3) is also allowed to modify its input parameter in
place, casting constness away from the strings we obtained from the
caller and giving them to basename is a no-no.
Reported, and initial fix and test supplied by David Rydh.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reported by: Johannes Sixt <j.sixt@viscovery.net>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It forgot to apply the prefix to the paths given on the command line.
[jc: added test]
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
