v1.6.1.3~4^2 (Fix gitdir detection when in subdir of gitdir,
2009-01-16) did not go far enough: when a git directory is
an ancestor of the original working directory, not only
should GIT_DIR be set to point to the .git directory, but
the original working directory should be restored before
carrying out the relevant command.
This way, the effect of running a git command from a subdir
of .git will be the same whether or not GIT_DIR is explicitly
set.
Noticed while investigating v1.6.0.3~1 (rehabilitate 'git
index-pack' inside the object store, 2008-10-20).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git apply", like most plumbing, does not automatically refresh the
index file even if it is only stat-dirty. So unless the two "cp"
commands in reset_preimage() for a given file happen to have the same
time stamp, there will be a spurious
error: sub/dir/file: does not match index
Refresh the index to eliminate this timing dependency. Noticed by
running the test with --valgrind (which slows things down a lot).
Reported-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This does not eliminate any code, but it skims some off of
the main loop of setup_git_directory_gently so that can be
understood more easily.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Perhaps some day, other similar conditions (hitting the mount point,
hitting the root of the file system) will share this code.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a repository is found as an ancestor of the original
working directory, it is assumed by default to be bare.
Handle this case with its own function.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The repository discovery procedure looks something like this:
while (same filesystem) {
check .git in working dir
check .
chdir(..)
}
Add a function for the first step to make the actual code look a bit
closer to that pseudocode.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If $GIT_DIR is set, setup_git_directory_gently does not have
to do any repository discovery at all. Split off a function
for the validation it still does do, in the hope that this will
make setup_git_directory_gently proper less daunting to read.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure git apply can apply patches with paths relative to the
toplevel of a work tree, a subdirectory, or within the repository
metadata directory.
Relative paths are broken for most commands when run from a
subdirectory of $GIT_DIR, "git apply" being no exception. The other
tests are meant to keep the demonstration of that company.
Based on a test by Duy.
Cc: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tweak the style of these tests to make them easier to read.
- Replace test_rev_parse() which produced multiple mini-tests with a
simple function that can be used with the test body.
- Combine multiple mini-tests into larger chunks that are easier
to read.
- Do not hard-code object IDs. We may use a different hash some day.
- Use test_cmp in preference to the test builtin. The former
produces useful output when tests are run with the "-v" option.
- Guard all test code with test_expect_success. This makes it much
easier to visually scan through the test and find code of interest.
- Use subshells to make the current directory easier to track.
Outside of any subshell, the current directory is always
$TEST_DIRECTORY now.
Also add a new test demonstrating a possible bug noticed in the
process of cleaning up: “git rev-parse --show-prefix” leaves out
the trailing newline after an empty prefix when cwd is at the
toplevel of the work tree.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These two tests weren't about how "git reflog show <branch>" exits when
there is no reflog, but were about "checkout" and "branch" create or not
create reflog when creating a new <branch>. Update the tests to check
what we are interested in, using "git rev-parse --verify".
Also lose tests based on "test -f .git/logs/refs/heads/<branch>" from
nearby, to avoid exposing this particular implementation detail
unnecessarily.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The correct advice should have been taken from c289c31 (t/t7006: ignore
return status of shell's unset builtin, 2010-06-02). A real-life issue
we experienced was with "unset", not with "export" (exporting an
unset variable may have similar portability issues, though).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '!()' notation is interpreted as a pattern-list on Ksh. The Ksh man
page describe it as follows:
!(pattern-list)
Matches anything except one of the given patterns.
Ksh performs a file glob using the pattern-list and then tries to execute
the first file in the list. If a space is added between the '!' and the
open parens, then Ksh will not interpret it as a pattern list, but in this
case, it is preferred to use test_must_fail, so lets do so.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These two lines use the negation '!' operator to negate the result of a
simple command. Since these commands do not contain any pipes or other
complexities, the test_must_fail function can be used and is preferred
since it will additionally detect termination due to a signal.
This was noticed because the second use of '!' does not include a space
between the '!' and the opening parens. Ksh interprets this as follows:
!(pattern-list)
Matches anything except one of the given patterns.
Ksh performs a file glob using the pattern-list and then tries to execute
the first file in the list. If a space is added between the '!' and the
open parens, then Ksh will not interpret it as a pattern list, but in this
case, it is preferred to use test_must_fail, so lets do so.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some have found the wording of the description to be somewhat ambiguous
with respect to when it is desirable to use test_must_fail instead of
"! <git-command>". Tweak the wording somewhat to hopefully clarify that
it is _because_ test_must_fail can detect segmentation fault that it is
desirable to use it instead of "! <git-command>".
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This prevents a buffer overrun that could otherwise be triggered by
creating a file called '.git' with contents
gitdir: (something really long)
Signed-off-by: Greg Brockman <gdb@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The correct responses to a D and a T line in .git/objects/info/packs
are the same, so combine their case arms. In both cases we already
‘goto’ out of the switch so while at it, remove a redundant ‘break’
to avoid yet another line of code.
Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Reviewed-by: Jonathan Nieder <jrnieder <at> gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All the git add options were listed in the synopsis until the
--ignore-missing option was added. Change that so that the git add
documentation now has the complete listing.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git submodule add no longer implicitly adds with --force. Remove
references to the old functionality in the documentation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To make the behavior of "git submodule add" more consistent with "git add"
ignored submodule paths should not be silently added when they match an
entry in a .gitignore file. To be able to override that default behavior
in the same way as we can do that for "git add", the new option "--force"
is introduced.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git mergetool' creates '*.orig' backup files in its
default configuration. Mention this in its documentation.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apparently using the Storable module during global destruction is
unsafe - there is a bug which can cause segmentation faults:
http://rt.cpan.org/Public/Bug/Display.html?id=36087http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482355
The persistent memoization support introduced in commit 8bff7c538
relied on global destruction to write cached data, which was leading
to segfaults in some Perl configurations. Calling Memoize::unmemoize
in the END block forces the cache writeout to be performed earlier,
thus avoiding the bug.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Acked-by: Eric Wong <normalperson@yhbt.net>
The current make target 'aggregate-results' scanned all files matching
test-results/t*-*. Normally these are only the test counts (and the
exit values, which are ignored), but with --tee the suite also dumps
all output. Furthermore, with --verbose t1450 contains several lines
starting with "broken link from ..." which matches the criteria used
by aggregate-results.sh.
Rename the counts output files to *.counts, and only scan those.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The svn-fe tool takes a Subversion dump file as input and produces
a fast-import stream as output. This can be useful as a low-level
tool in building other importers, or for debugging the vcs-svn
library.
make svn-fe
make svn-fe.1
to test.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier we tried to make sure that the trees we get are what A...B
syntax produced, by checking that earlier ones are all marked
uninteresting (which has to be true as they are merge bases),
there are two remaining ones that are interesting, and they are
marked as non-symmetric-left and symmetric-left respectively.
The "the last two must be interesting" condition is however wrong when one
is an ancestor of the other between A and B (i.e. fast-forward). In such
a case, one of them is marked uninteresting.
* jn/paginate-fix:
git --paginate: paginate external commands again
git --paginate: do not commit pager choice too early
tests: local config file should be honored from subdirs of toplevel
t7006: test pager configuration for several git commands
t7006 (pager): introduce helper for parameterized tests
Conflicts:
t/t7006-pager.sh
* mg/revision-doc:
Documentation: link to gitrevisions rather than git-rev-parse
Documentation: gitrevisions
Documentation: split off rev doc into include file
* bc/maint-makefile-fixes:
Makefile: work around ksh's failure to handle missing list argument to for loop
Makefile: remove some unnecessary curly braces
The url, path, and the update items in [submodule "foo"] stanzas
are nicely explained in the .gitmodules and ‘git submodule’
documentation. Point there from the config documentation.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is already excellent documentation for this facility in
git-submodule.1, but it is not so discoverable.
Relative paths in .gitmodules can be useful for serving the
same repository over multiple protocols, for example.
Thanks to Peter for pointing this out.
Cc: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, 452e225 (gitweb: fix esc_param, 2009-10-13) fixed CGI escaping
rules used in esc_url. A very similar logic exists in esc_param and needs
to be fixed the same way.
Signed-off-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
73e25e7c (git --paginate: do not commit pager choice too early,
2010-06-26) failed to take some cases into account.
1b. Builtins that do not use RUN_SETUP (like git config) do
not find GIT_DIR set correctly when the pager is launched
from run_builtin(). So the core.pager configuration is
not honored from subdirectories of the toplevel for them.
4a. External git commands (like git request-pull) relied on the
early pager launch to take care of handling the -p option.
Ever since 73e25e7c, they do not honor the -p option at all.
4b. Commands invoked through ! aliases (like ls) were also relying
on the early pager launch.
Fix (4a) by launching the pager (if requested) before running such a
“dashed external”. For simplicity, this still does not search for a
.git directory before running the external command; when run from a
subdirectory of the toplevel, therefore, the “[core] pager”
configuration is still not honored.
Fix (4b) by launching pager if requested before carrying out such an
alias. Actually doing this has no effect, since the pager (if any)
would have already been launched in a failed attempt to try a
dashed external first. The choice-of-pager-not-honored-from-
subdirectory bug still applies here, too.
(1b) is not a regression. There is no need to fix it yet.
Noticed by Junio.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
0af0ac7 (Move MERGE_RR from .git/rr-cache/ into .git/) moved the
location of MERGE_RR but I found a few references to the old
location.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
15b4f7a (merge-tree: use ll_merge() not xdl_merge(), 2010-01-16)
introduced a regression to merge-tree to cause it to segfault when merging
files which existed in one branch, but not in the other or in the
merge-base. This was caused by referencing entry->path at a time when
entry was known to be possibly-NULL.
To correct the problem, we save the path of the entry we came in with,
as the path should be the same among all the stages no matter which
sides are involved in the merge.
Signed-off-by: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
