The test cases include many corner-cases of merge-recursive's behavior,
some of them involve type changes and symbolic links. All cases, including
those that are protected by SYMLINKS check only whether the result of
merge-recursive is correctly stored in the database and the index; the
file system is not investigated. Use test_ln_s_add to enter a symbolic
link in the index in the test setup and run the tests without the
SYMLINKS prerequisite.
Notice that one test that has the SYMLINKS protection removed is an
expect_failure. There is a possibility that the test fails differently
depending on whether SYMLINKS is present or not; but this is not the case
presently.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t0000-basic hard-codes many object IDs. To cater to file systems that do
not support symbolic links, different IDs are used depending on the
SYMLINKS prerequisite. But we can observe the symbolic links are only
needed to generate index entries. Use test_ln_s_add to generate the
index entries and get rid of explicit SYMLINKS checks.
This undoes the special casing introduced in this test by 704a3143
(Use prerequisite tags to skip tests that depend on symbolic links,
2009-03-04).
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are many instances where the treatment of symbolic links in the
object model and the algorithms are tested, but where it is not
necessary to actually have a symbolic link in the worktree. Make
adjustments to the tests and remove the SYMLINKS prerequisite when
appropriate in trivial cases, where "trivial" means:
- merely a replacement of 'ln -s a b && git add b' by test_ln_s_add
is needed;
- a test for symbolic link on the file system can be split off (and
remains protected by SYMLINKS);
- existing code is equivalent to test_ln_s_add.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a new function that creates a symbolic link and adds it to the index
to be used in cases where a symbolic link is not required on the file
system. We will use it to remove many SYMLINKS prerequisites from test
cases.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular:
- move test preparations inside test_expect_success
- place test description on the test_expect_success line
- indent with a tab
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a header file to define a macro that can define the struct
type, initializer, accessor and cleanup functions to manage a commit
slab. Update the "indegree" topological sort facility using it.
To associate 32 flag bits with each commit, you can write:
define_commit_slab(flag32, uint32);
to declare "struct flag32" type, define an instance of it with
struct flag32 flags;
and initialize it by calling
init_flag32(&flags);
After that, a call to flag32_at() function
uint32 *fp = flag32_at(&flags, commit);
will return a pointer pointing at a uint32 for that commit. Once
you are done with these flags, clean them up with
clear_flag32(&flags);
Callers that cannot hard-code how wide the data to be associated
with the commit be at compile time can use the "_with_stride"
variant to initialize the slab.
Suppose you want to give one bit per existing ref, and paint commits
down to find which refs are descendants of each commit. Saying
typedef uint32 bits320[5];
define_commit_slab(flagbits, bits320);
at compile time will still limit your code with hard-coded limit,
because you may find that you have more than 320 refs at runtime.
The code can declare a commit slab "struct flagbits" like this
instead:
define_commit_slab(flagbits, unsigned char);
struct flagbits flags;
and initialize it by:
nrefs = ... count number of refs ...
init_flagbits_with_stride(&flags, (nrefs + 7) / 8);
so that
unsigned char *fp = flagbits_at(&flags, commit);
will return a pointer pointing at an array of 40 "unsigned char"s
associated with the commit, once you figure out nrefs is 320 at
runtime.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3406 is supposed to test "messages from rebase operation", so let's
move tests in t3400 that fit that description into 3406. Most of the
functionality they tested, except for the messages, has now been
subsumed by t3420.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update the following:
- Quote 'setup'
- Remove blank lines within test case body
- Use test_commit instead of custom quick_one
- Create branch "topic" from tag created by test_commit
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The bug is manifest when running gitweb in a persistent process (e.g.
FastCGI, PSGI), and it's easy to reproduce. If a gitweb request
includes the searchtext parameter (i.e. s), subsequent requests using
the project_list action--which is the default action--and without
a searchtext parameter will be filtered by the searchtext value of the
first request. This is because the value of the $search_regexp global
(the value of which is based on the searchtext parameter) is currently
being persisted between requests.
Instead, clear $search_regexp before dispatching each request.
Signed-off-by: Charles McGarvey <chazmcgarvey@brokenzipper.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When explaining the "--tags" option as an equivalent to giving an
explicit "refs/tags/*:refs/tags/*" refspec, the two asterisks were
misinterpreted by AsciiDoc as a request to typeset the string
segment between them in bold.
We could fix it in two ways. We can replace them with {asterisk}s
while keeping the string as body text, or we can mark it as a
literal string with backquotes around it.
Let's do the latter, as it is teaching the user an "exactly as
typed" alternative.
Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This set of patches collects a number of build fixes that have been
used on the msysgit port for a while and merging upstream should
simplify future maintenance.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQCVAwUAUbEmnGB90JXwhOSJAQKRJgP/TdWucLnedP4tRKhRrwy3AnZ2Her4Mn5n
isrNQu3eixT3PsGzdyYUvTYLP8OPNfgYYVEzqyrRtNHKKSD2qLGXt8oyOw63z10n
tiDcHHCfI1U/W7GHK1Q9abaQz/PF6yWnYenRt9lnckyqtxNoa8o+eOCfuY9lBfNJ
ccTP/dRgoL0=
=uWg2
-----END PGP SIGNATURE-----
Merge tag 'post183-for-junio' of http://github.com/msysgit/git
Collected msysgit build patches for upstream
This set of patches collects a number of build fixes that have been
used on the msysgit port for a while and merging upstream should
simplify future maintenance.
* tag 'post183-for-junio' of http://github.com/msysgit/git:
Set the default help format to html for msys builds.
Ensure the resource file is rebuilt when the version changes.
Windows resource: handle dashes in the Git version gracefully
Provide a Windows version resource for the git executables.
msysgit: Add the --large-address-aware linker directive to the makefile.
Define NO_GETTEXT for Git for Windows
Makefile: Do not use OLD_ICONV on MINGW anymore
On Mac OS X, any application that is started from the Terminal will open
behind all running applications; as a work-around, manually bring ourselves
to the front. (Stolen from gitk, commit 76bf6ff93e.)
We do this as the very first thing, so that any message boxes that might pop
up during the rest of the startup sequence are actually seen by the user.
[PT: added catch and moved down to ensure Tk has been loaded]
Signed-off-by: Stefan Haller <stefan@haller-berlin.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
"git push $there HEAD:branch" did not resolve HEAD early enough, so
it was easy to flip it around while push is still going on and push
out a branch that the user did not originally intended when the
command was started.
* rr/push-head:
push: make push.default = current use resolved HEAD
push: fail early with detached HEAD and current
push: factor out the detached HEAD error message
"difftool --dir-diff" did not copy back changes made by the
end-user in the diff tool backend to the working tree in some
cases.
* ks/difftool-dir-diff-copy-fix:
difftool --dir-diff: allow changing any clean working tree file
The bash prompt code (in contrib/) displayed the name of the branch
being rebased when "rebase -i/-m/-p" modes are in use, but not the
plain vanilla "rebase".
* fc/show-branch-in-rebase-am:
prompt: fix for simple rebase
Special case "git clone" and use lighter-weight implementation to
check the completeness of the history behind refs.
* nd/clone-connectivity-shortcut:
clone: open a shortcut for connectivity check
index-pack: remove dead code (it should never happen)
fetch-pack: prepare updated shallow file before fetching the pack
clone: let the user know when check_everything_connected is run
With "export" remote-helper protocol,
(1) a push that tries to update a remote ref whose name is
different from the pushing side does not work yet, and
(2) the helper may not know how to do --dry-run
Detect such problematic cases and disable them for now.
* fc/transport-helper-no-refspec:
transport-helper: check if the dry-run is supported
transport-helper: barf when user tries old:new
Many code paths will free a tree object's buffer and set it
to NULL after finishing with it in order to keep memory
usage down during a traversal. However, out of 8 sites that
do this, only one actually unsets the "parsed" flag back.
Those sites that don't are setting a trap for later users of
the tree object; even after calling parse_tree, the buffer
will remain NULL, causing potential segfaults.
It is not known whether this is triggerable in the current
code. Most commands do not do an in-memory traversal
followed by actually using the objects again. However, it
does not hurt to be safe for future callers.
In most cases, we can abstract this out to a
"free_tree_buffer" helper. However, there are two
exceptions:
1. The fsck code relies on the parsed flag to know that we
were able to parse the object at one point. We can
switch this to using a flag in the "flags" field.
2. The index-pack code sets the buffer to NULL but does
not free it (it is freed by a caller). We should still
unset the parsed flag here, but we cannot use our
helper, as we do not want to free the buffer.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test case depends on that test-sigchain can commit suicide by a
call to raise(SIGTERM) in a way that run-command.c::wait_or_whine()
can detect as death through a signal. There are no POSIX signals on
Windows, and a sufficiently close emulation is not available in the
Microsoft C runtime (and probably not even possible).
The particular deficiency is that when a signal is raise()d whose
SIG_DFL action will cause process death (SIGTERM in this case), the
implementation of raise() in msvcrt just calls exit(3).
We could check for exit code 3 in addition to 143, but that would
miss the point of the test entirely. Hence, just skip it on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git commit --allow-empty-message -m ''" should not start an
editor.
* rs/commit-m-no-edit:
commit: don't start editor if empty message is given with -m
An overdue removal of "behaviour changed at 1.7.0; if you were
living in a cave, here is what you can adjust to it" message.
* fc/send-email-chainreplyto-warning:
send-email: remove warning about unset chainreplyto
Update Makefile to use handy automatic variables where appropriate,
and stop installing a script that is only used for testing.
* fc/makefile:
build: do not install git-remote-testpy
build: add NO_INSTALL variable
build: cleanup using $<
build: cleanup using $^
build: trivial simplification
zsh prompt script that borrowed from bash prompt script did not
work due to slight differences in array variable notation between
these two shells.
* tg/maint-zsh-svn-remote-prompt:
prompt: fix show upstream with svn and zsh
It turns out that git-subtree script does not have to be run with
bash.
* dm/unbash-subtree:
contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash
Prompt support (in contrib/) for zsh is updated to use colors.
* rr/zsh-color-prompt:
prompt: colorize ZSH prompt
prompt: factor out gitstring coloring logic
prompt: introduce GIT_PS1_STATESEPARATOR
The configuration variable core.checkstat was advertised in the
documentation but the code expected core.statinfo instead.
For now, we accept both core.checkstat and core.statinfo, but the
latter will be removed in the longer term.
* jc/core-checkstat:
deprecate core.statinfo at Git 2.0 boundary
Users can sanitize from address manually.
Verify that these are suppressed properly.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
add test where sender address needs to be quoted.
Make sure --suppress-cc=self works well in this case.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--suppress-cc=self fails to filter sender address in many cases where it
needs to be sanitized in some way, for example quoted:
"A U. Thor" <author@example.com>
To fix, make send-email sanitize both sender and the address it is
compared against.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check that suppress-cc=self works when applied
to output of cccmd.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cccmd is used, old-style suppress-from filter
is applied by the newer suppress-cc=self isn't.
Fix this up.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 52dce6d, a new credential function was added to Git.pm, based on
git-remote-mediawiki's functions. The logical follow-up is to use
those functions in git-remote-mediawiki.
Signed-off-by: Benoit Person <benoit.person@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a test wants to make sure there is no <string> in an output
file, we should just say "! grep string output".
"test_must_fail" is there only to test Git command and catch unusual
deaths we know about (e.g. segv) as an error, not as an expected
failure. "test_must_fail grep string output" is unnecessary, as
we are not making sure the system binaries do not dump core or
anything like that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
