* rj/config-cygwin:
config.c: Make git_config() work correctly when called recursively
t1301-*.sh: Fix the 'forced modes' test on cygwin
help.c: Fix detection of custom merge strategy on cygwin
* fg/submodule-keep-updating:
git-submodule.sh: clarify the "should we die now" logic
submodule update: continue when a checkout fails
git-sh-setup: add die_with_status
* an/shallow-doc:
Document the underlying protocol used by shallow repositories and --depth commands.
Fix documentation of fetch-pack that implies that the client can disconnect after sending wants.
This has been there since textconv existed, but was never
documented. There is some overlap with what's in
gitattributes(5), but it's important to warn in both places
that textconv diffs probably can't be applied.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/streaming-filter:
t0021: test application of both crlf and ident
t0021-conversion.sh: fix NoTerminatingSymbolAtEOF test
streaming: filter cascading
streaming filter: ident filter
Add LF-to-CRLF streaming conversion
stream filter: add "no more input" to the filters
Add streaming filter API
convert.h: move declarations for conversion from cache.h
* jn/gitweb-js-blame:
gitweb.js: use setTimeout rather than setInterval in blame_incremental.js
gitweb.js: No need for loop in blame_incremental's handleResponse()
gitweb.js: No need for inProgress in blame_incremental.js
* da/git-prefix-everywhere:
t/t7503-pre-commit-hook.sh: Add GIT_PREFIX tests
git-mergetool--lib: Make vimdiff retain the current directory
git: Remove handling for GIT_PREFIX
setup: Provide GIT_PREFIX to built-ins
* jc/streaming:
sha1_file: use the correct type (ssize_t, not size_t) for read-style function
streaming: read loose objects incrementally
sha1_file.c: expose helpers to read loose objects
streaming: read non-delta incrementally from a pack
streaming_write_entry(): support files with holes
convert: CRLF_INPUT is a no-op in the output codepath
streaming_write_entry(): use streaming API in write_entry()
streaming: a new API to read from the object store
write_entry(): separate two helper functions out
unpack_object_header(): make it public
sha1_object_info_extended(): hint about objects in delta-base cache
sha1_object_info_extended(): expose a bit more info
packed_object_info_detail(): do not return a string
* ef/maint-win-verify-path:
verify_dotfile(): do not assume '/' is the path seperator
verify_path(): simplify check at the directory boundary
verify_path: consider dos drive prefix
real_path: do not assume '/' is the path seperator
A Windows path starting with a backslash is absolute
* js/i18n-windows:
Windows: teach getenv to do a case-sensitive search
mingw.c: move definition of mingw_getenv down
sh-i18n--envsubst: do not crash when no arguments are given
* jk/combine-diff-binary-etc:
combine-diff: respect textconv attributes
refactor get_textconv to not require diff_filespec
combine-diff: handle binary files as binary
combine-diff: calculate mode_differs earlier
combine-diff: split header printing into its own function
Merge branch 'instaweb' of git://bogomips.org/git-svn
* 'instaweb' of git://bogomips.org/git-svn:
git-instaweb: Check that correct config file exists for (re)start
git-instaweb: Move all actions at the end of script
git-instaweb: Use $conf, not $fqgitdir/gitweb/httpd.conf
git-instaweb: Extract configuring web server into configure_httpd
test: skip clean-up when running under --immediate mode
Some tests try to be too careful about cleaning themselves up and
do
test_expect_success description '
set-up some test refs and/or configuration &&
test_when_finished "revert the above changes" &&
the real test
'
Which is nice to make sure that a potential failure would not have
unexpected interaction with the next test. This however interferes when
"the real test" fails and we want to see what is going on, by running the
test with --immediate mode and descending into its trash directory after
the test stops. The precondition to run the real test and cause it to fail
is all gone after the clean-up procedure defined by test_when_finished is
done.
Update test_run_ which is the workhorse of running a test script
called from test_expect_success and test_expect_failure, so that we do not
run clean-up script defined with test_when_finished when a test that is
expected to succeed fails under the --immediate mode.
Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Jeff King <peff@peff.net>
git-svn: Correctly handle root commits in mergeinfo ranges
If the bottom of a mergeinfo range is a commit that maps to a git root
commit, then it doesn't have a parent. In such a case, use git commit
range "$top_commit" rather than "$bottom_commit^..$top_commit".
[ew: line-wrap at 80 columns]
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: Demonstrate a bug with root commits in mergeinfo ranges
If a svn:mergeinfo range starts at a commit that was converted as a
git root commit (e.g., r1 or a branch that was created out of thin
air), then there is an error when git-svn tries to run
git rev-list "$bottom_commit^..$top_commit"
because $bottom_commit (the git commit corresponding to r1) has no
parent.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Acked-by: Eric Wong <normalperson@yhbt.net>
git-instaweb: Check that correct config file exists for (re)start
Currently start/restart does not generate any configuration files for
spawning a new instance. This means that
$ git instaweb --http=<server> --start
might pick up stale 'httpd.conf' file for a different web server
(e.g. for default lighttpd when requesting apache2).
This commit changes that, and makes git-instaweb generate web server
config file and/or gitweb config file if don't exists.
This required naming config files after the name of web server
(alternate solution would be to somehow mark for which web server was
config file generated).
Note that web servers that embed configuration in server script file,
namely webrick and plackup, and which delete "$conf" in their *_conf
function, would have their config (server script) always regenerated.
Note: this commit introduces a bit of code repetition (but only a few
lines).
Reported-by: Gurjeet Singh <singh.gurjeet@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
git-instaweb: Move all actions at the end of script
As a nice side-effect now the order of parameters does not matter:
$ git instaweb --httpd=apache2 --start
is now (after this patch) the same as
$ git instaweb --start --httpd=apache2
Before this commit --start, --stop, --restart (and their subcommand
versions start, stop, restart) exited immediately.
This is preparatory work for making start/restart check that correct
configuration is set up; this change was required to have access in
start_httpd to requested web browser etc.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
gitweb: 'pickaxe' and 'grep' features requires 'search' to be enabled
Both 'pickaxe' (searching changes) and 'grep' (searching files)
require basic 'search' feature to be enabled to work. Enabling
e.g. only 'pickaxe' won't work.
Add a comment about this.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael J Gruber noticed that under /bin/dash this test failed
(as is expected -- \n in the string can be interpreted by the
command), while it passed with bash. We probably could work it
around by using backquote in front of it, but it is safer and
more readable to avoid "echo" altogether in a case like this.
Earlier 7974843 (compat/cygwin.c: make runtime detection of lstat/stat
lessor impact, 2008-10-23) fixed the low-level "do we use cygwin specific
hacks for stat/lstat?" logic not to call into git_default_config() from
random codepaths that are typically very late in the program, to prevent
the call from potentially overwriting other variables that are initialized
from the configuration.
However, it forgot that on Cygwin, trust-executable-bit should default to
true.
Noticed by J6t, confirmed by Ramsay Jones, and the brown paper bag is on
Gitster's head.
fetch: Also fetch submodules in subdirectories in on-demand mode
When on-demand mode was active examining the new commits just fetched in
the superproject (to check if they record commits for submodules which are
not downloaded yet) wasn't done recursively. Because of that fetch did not
recursively fetch submodules living in subdirectories even when it should
have.
Fix that by adding the RECURSIVE flag to the diff_options used to check
the new commits and avoid future regressions in this area by moving a
submodule in t5526 into a subdirectory.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i -p: include non-first-parent commits in todo list
Consider this graph:
D---E (topic, HEAD)
/ /
A---B---C (master)
\
F (topic2)
and the following three commands:
1. git rebase -i -p A
2. git rebase -i -p --onto F A
3. git rebase -i -p B
Currently, (1) and (2) will pick B, D, C, and E onto A and F,
respectively. However, (3) will only pick D and E onto B, but not C,
which is inconsistent with (1) and (2). As a result, we cannot modify C
during the interactive-rebase.
The current behavior also creates a bug if we do:
4. git rebase -i -p C
In (4), E is never picked. And since interactive-rebase resets "HEAD"
to "onto" before picking any commits, D and E are lost after the
interactive-rebase.
This patch fixes the inconsistency and bug by ensuring that all children
of upstream are always picked. This essentially reverts the commit: d80d6bc146232d81f1bb4bc58e5d89263fd228d4
When compiling the todo list, commits reachable from "upstream" should
never be skipped under any conditions. Otherwise, we lose the ability
to modify them like (3), and create a bug like (4).
Two of the tests contain a scenario like (3). Since the new behavior
added more commits for picking, these tests need to be updated to
account for the additional pick lines. A new test has also been added
for (4).
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
tests: link shell libraries into valgrind directory
When we run tests under valgrind, we symlink anything
executable that starts with git-* or test-* into a special
valgrind bin directory, and then make that our
GIT_EXEC_PATH.
However, shell libraries like git-sh-setup do not have the
executable bit marked, and did not get symlinked. This
means that any test looking for shell libraries in our
exec-path would fail to find them, even though that is a
fine thing to do when testing against a regular git build
(or in a git install, for that matter).
t2300 demonstrated this problem. The fix is to symlink these
shell libraries directly into the valgrind directory.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/Makefile: pass test opts to valgrind target properly
The valgrind target just reinvokes make with GIT_TEST_OPTS
set to "--valgrind". However, it does this using an
environment variable, which means GIT_TEST_OPTS in your
config.mak would override it, and "make valgrind" would
simply run the test suite without valgrind on.
Instead, we should pass GIT_TEST_OPTS on the command-line,
overriding what's in config.mak, and take care to append to
whatever the user has there already.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The getopt.h header file is not used. It's inclusion is left over from the
original version of this source. Additionally, getopt.h does not exist on
all platforms (SunOS 5.7) and will cause a compilation failure. So, let's
remove it.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
config.c: Make git_config() work correctly when called recursively
On Cygwin, this fixes a test failure in t3301-notes.sh (test 98,
"git notes copy --for-rewrite (disabled)").
The test failure is caused by a recursive call to git_config() which
has the effect of skipping to the end-of-file while processing the
"notes.rewriteref" config variable. Thus, any config variables that
appear after "notes.rewriteref" are simply ignored by git_config().
Also, we note that the original FILE handle is leaked as a result
of the recursive call.
The recursive call to git_config() is due to the "schizophrenic stat"
functions on cygwin, where one of two different implementations of
the l/stat functions is selected lazily, depending on some config
variables.
In this case, the init_copy_notes_for_rewrite() function calls
git_config() with the notes_rewrite_config() callback function.
This callback, while processing the "notes.rewriteref" variable,
in turn calls string_list_add_refs_by_glob() to process the
associated ref value. This eventually leads to a call to the
get_ref_dir() function, which in turn calls stat(). On cygwin,
the stat() macro leads to an indirect call to cygwin_stat_stub()
which, via init_stat(), then calls git_config() in order to
determine which l/stat implementation to bind to.
In order to solve this problem, we modify git_config() so that the
global state variables used by the config reading code is packaged
up and managed on a local state stack.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'forced modes' test fails on cygwin because the post-update
hook loses it's executable bit when copied from the templates
directory by git-init. The template loses it's executable bit
because the lstat() function resolves to the "native Win32 API"
implementation.
This call to lstat() happens after git-init has set the "git_dir"
(so has_git_dir() returns true), but before the configuration has
been fully initialised. At this point git_config() does not find
any config files to parse and returns 0. Unfortunately, the code
used to determine the cygwin l/stat() function bindings did not
check the return from git_config() and assumed that the config
was complete and accessible once "git_dir" was set.
In order to fix the test, we simply change the binding code to
test the return value from git_config(), to ensure that it actually
had config values to read, before determining the requested binding.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
help.c: Fix detection of custom merge strategy on cygwin
Test t7606-merge-custom.sh fails on cygwin when git-merge fails
with an "Could not find merge strategy 'theirs'" error, despite
the test correctly preparing an (executable) git-merge-theirs
script.
The cause of the failure is the mis-detection of the executable
status of the script, by the is_executable() function, while the
load_command_list() function is searching the path for additional
merge strategy programs.
Note that the l/stat() "functions" on cygwin are somewhat
schizophrenic (see commits adbc0b6, 7faee6b and 7974843), and
their behaviour depends on the timing of various git setup and
config function calls. In particular, until the "git_dir" has
been set (have_git_dir() returns true), the real cygwin (POSIX
emulating) l/stat() functions are called. Once "git_dir" has
been set, the "native Win32 API" implementations of l/stat()
may, or may not, be called depending on the setting of the
core.filemode and core.ignorecygwinfstricks config variables.
We also note that, since commit c869753, core.filemode is forced
to false, even on NTFS, by git-init and git-clone. A user (or a
test) can, of course, reset core.filemode to true explicitly if
the filesystem supports it (and he doesn't use any problematic
windows software). The test-suite currently runs all tests on
cygwin with core.filemode set to false.
Given the above, we see that the built-in merge strategies are
correctly detected as executable, since they are checked for
before "git_dir" is set, whereas all custom merge strategies are
not, since they are checked for after "git_dir" is set.
In order to fix the mis-detection problem, we change the code in
is_executable() to re-use the conditional WIN32 code section,
which actually looks at the content of the file to determine if
the file is executable. On cygwin we also make the additional
code conditional on the executable bit of the file mode returned
by the initial stat() call. (only the real cygwin function would
set the executable bit in the file mode.)
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
refs.c had a error message "Trying to write ref with nonexistant object".
And no tests relied on the wrong spelling.
Also typo was present in some test scripts internals, these tests still pass.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/gitweb-lib.sh: skip gitweb tests when perl dependencies are not met
Linus noticed that we go ahead testing gitweb and fail miserably on a
box with Perl but not perl-CGI library. We already have a code to detect
lack of Perl and refrain from testing gitweb in t/gitweb-lib.sh (by the
way, shouldn't it be called t/lib-gitweb.sh?), so let's extend it
to cover this case as well.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
in openSUSE /etc/mime.types has only spaces. I don't know if there's
a canonical reference that says that only tabs are allowed. Mutt at
least also accepts spaces. So make gitweb more liberal too.
Signed-off-by: Ludwig Nussel <ludwig.nussel@suse.de> Acked-by: Jakub Narebski <jnareb@gmail.com> Acked-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-submodule.sh: clarify the "should we die now" logic
Earlier the decision to stop or continue was made on the $action variable
that was set by inspecting $update_module variable. The former is a
redundant variable and will be removed in another topic.
Decide upon inspecting $update_module if a failure should cascade up to
cause us immediately stop, and use a variable that means just that, to
clarify the logic.
Incidentally this also makes the merge with the other topic slightly
easier and cleaner to understand.
"git submodule update" stops at the first error and gives control
back to the user. Only after the user fixes the problematic
submodule and runs "git submodule update" again, the second error
is found. And the user needs to repeat until all the problems are
found and fixed one by one. This is tedious.
Instead, the command can remember which submodules it had trouble with,
continue updating the ones it can, and report which ones had errors at
the end. The user can run "git submodule update", find all the ones that
need minor fixing (e.g. working tree was dirty) to fix them in a single
pass. Then another "git submodule update" can be run to update all.
Note that the problematic submodules are skipped only when they are to
be integrated with a safer value of submodule.<name>.update option,
namely "checkout". Fixing a failure in a submodule that uses "rebase" or
"merge" may need an involved conflict resolution by the user, and
leaving too many submodules in states that need resolution would not
reduce the mental burden on the user.
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: do not misparse nonnumeric content tag files that contain a digit
v1.7.6-rc0~27^2~4 (gitweb: Change the way "content tags" ('ctags') are
handled, 2011-04-29) tried to make gitweb's tag cloud feature more
intuitive for webmasters by checking whether the ctags/<label> under
a project's .git dir contains a number (representing the strength of
association to <label>) before treating it as one.
With that change, after putting '$feature{'ctags'}{'default'} = [1];'
in your $GITWEB_CONFIG, you could do
echo Linux >.git/ctags/linux
and gitweb would treat that as a request to tag the current repository
with the Linux tag, instead of the previous behavior of writing an
error page embedded in the projects list that triggers error messages
from Chromium and Firefox about malformed XML.
Unfortunately the pattern (\d+) used to match numbers is too loose,
and the "XML declaration allowed only at the start of the document"
error can still be experienced if you write "Linux-2.6" in place of
"Linux" in the example above. Fix it by tightening the pattern to
^\d+$.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document the underlying protocol used by shallow repositories and --depth commands.
Explain the exchange that occurs between a client and server when
the client is requesting shallow history and/or is already using
a shallow repository.
Signed-off-by: Alex Neronskiy <zakmagnus@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix documentation of fetch-pack that implies that the client can disconnect after sending wants.
Specify conditions under which the client can terminate the connection
early. Previously, an unintended behavior was possible which could
confuse servers.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Alex Neronskiy <zakmagnus@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_file.c: "legacy" is really the current format
Every time I look at the read-loose-object codepath, legacy_loose_object()
function makes my brain go through mental contortion. When we were playing
with the experimental loose object format, it may have made sense to call
the traditional format "legacy", in the hope that the experimental one
will some day replace it to become official, but it never happened.
This renames the function (and negates its return value) to detect if we
are looking at the experimental format, and move the code around in its
caller which used to do "if we are looing at legacy, do this special case,
otherwise the normal case is this". The codepath to read from the loose
objects in experimental format is the "unlikely" case.
Someday after Git 2.0, we should drop the support of this format.
verify_path(): simplify check at the directory boundary
We simply want to say "At a directory boundary, be careful with a name
that begins with a dot, forbid a name that ends with the boundary
character or has duplicated bounadry characters".
* jn/gitweb-docs:
gitweb: Move "Requirements" up in gitweb/INSTALL
gitweb: Describe CSSMIN and JSMIN in gitweb/INSTALL
gitweb: Move information about installation from README to INSTALL
* bc/maint-status-z-to-use-porcelain:
builtin/commit.c: set status_format _after_ option parsing
t7508: demonstrate status's failure to use --porcelain format with -z
Windows: teach getenv to do a case-sensitive search
getenv() on Windows looks up environment variables in a case-insensitive
manner. Even though all documentations claim that the environment is
case-insensitive, it is possible for applications to pass an environment
to child processes that has variables that differ only in case. Bash on
Windows does this, for example, and sh-i18n--envsubst depends on this
behavior.
With this patch environment variables are first looked up in a
case-sensitive manner; only if this finds nothing, the system's getenv() is
used as a fallback.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We want to use static lookup_env() in a subsequent change.
At first sight, this change looks innocent. But it is not due to the
#undef getenv. There is one caller of getenv between the old location and
the new location whose behavior could change. But as can be seen from the
defintion of mingw_getenv, the behavior for this caller does not change
substantially.
To ensure consistent behavior in the future, change all getenv callers
in mingw.c to use mingw_getenv.
With this patch, this is not a big deal, yet, but with the subsequent
change, where we teach getenv to do a case-sensitive lookup, the behavior
of all call sites is changed.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When create a new branch, we fed "refs/heads/<proposed name>" as a string
to get_sha1() and expected it to fail when a branch already exists.
The right way to check if a ref exists is to check with resolve_ref().
A naïve solution that might appear attractive but does not work is to
forbid slashes in get_describe_name() but that will not work. A describe
name is is in the form of "ANYTHING-g<short sha1>", and that ANYTHING part
comes from a original tag name used in the repository the user ran the
describe command. A sick user could have a confusing hierarchical tag
whose name is "refs/heads/foobar" (stored as refs/tags/refs/heads/foobar")
to generate a describe name "refs/heads/foobar-6-g02ac983", and we should
be able to use that name to refer to the object whose name is 02ac983.
With --heading, the filename is printed once before matches from that
file instead of at the start of each line, giving more screen space to
the actual search results.
This option is taken from ack (http://betterthangrep.com/). And now
git grep can dress up like it:
With --break, an empty line is printed between matches from different
files, increasing readability. This option is taken from ack
(http://betterthangrep.com/).
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 431d6e7b (grep: enable threading for context line printing)
split the printing of the "--\n" mark between results from different
files out into two places: show_line() in grep.c for the non-threaded
case and work_done() in builtin/grep.c for the threaded case. Commit 55f638bd (grep: Colorize filename, line number, and separator) updated
the former, but not the latter, so the separators between files are
not colored if threads are used.
This patch merges the two. In the threaded case, hunk marks are now
printed by show_line() for every file, including the first one, and the
very first mark is simply skipped in work_done(). This ensures that the
output is properly colored and works just as well.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
With XSS prevention on (enabled using $prevent_xss), blobs
('blob_plain') of all types except a few known safe ones are served
with "Content-Disposition: attachment". However the check was too
strict; it didn't take into account optional parameter attributes,
http: pass http.cookiefile using CURLOPT_COOKIEFILE
If the config option http.cookiefile is set, pass this file to libCURL using
the CURLOPT_COOKIEFILE option. This is similar to calling curl with the -b
option. This allows git http authorization with authentication mechanisms
that use cookies, such as SAML Enhanced Client or Proxy (ECP) used by
Shibboleth.
To use SAML/ECP, the user needs to request a session cookie with their own ECP
code. See for example: