We check that we can "--get-all" a multi-valued variable,
but we do not actually confirm that the output is sensible.
Doing so reveals that it works fine, but this will help us
ensure we do not have regressions in the next few patches,
which will touch this area.
Signed-off-by: Jeff King <peff@peff.net>
This test checks that git-config fails for an ambiguous
"get", but we check the exact same thing 3 tests beforehand.
Signed-off-by: Jeff King <peff@peff.net>
The t1300 test script is quite old, and does not use our
modern techniques or styles. This patch updates it in the
following ways:
1. Use test_cmp instead of cmp (to make failures easier to
debug).
2. Use test_cmp instead of 'test $(command) = expected'.
This makes failures much easier to debug, and also
makes sure that $(command) exits appropriately.
3. Use test_must_fail (easier to read, and checks more
rigorously for signal death).
4. Write tests with the usual style of:
test_expect_success 'test name' '
test commands &&
...
'
rather than one-liners, or using backslash-continuation.
This is purely a style fixup.
There are still a few command happening outside of
test_expect invocations, but they are all innoccuous system
commands like "cat" and "cp". In an ideal world, each test
would be self sufficient and all commands would happen
inside test_expect, but it is not immediately obvious how
the grouping should work (some of the commands impact the
subsequent tests, and some of them are setting up and
modifying state that many tests depend on). This patch just
picks the low-hanging style fruit, and we can do more fixes
on top later.
Signed-off-by: Jeff King <peff@peff.net>
This test script uses "svn cp" to create a branch with an @-sign in
its name:
svn cp "pr ject/trunk" "pr ject/branches/not-a@{0}reflog"
That sets up for later tests that fetch the branch and check that git
svn mangles the refname appropriately.
Unfortunately, modern svn versions interpret path arguments with an
@-sign as an example of path@revision syntax (which pegs a path to a
particular revision) and truncate the path or error out with message
"svn: E205000: Syntax error parsing peg revision '{0}reflog'".
When using subversion 1.6.x, escaping the @ sign as %40 avoids trouble
(see 08fd28bb, 2010-07-08). Newer versions are stricter:
$ svn cp "$repo/pr ject/trunk" "$repo/pr ject/branches/not-a%40{reflog}"
svn: E205000: Syntax error parsing peg revision '%7B0%7Dreflog'
The recommended method for escaping a literal @ sign in a path passed
to subversion is to add an empty peg revision at the end of the path
("branches/not-a@{0}reflog@"). Do that.
Pre-1.6.12 versions of Subversion probably treat the trailing @ as
another literal @-sign (svn issue 3651). Luckily ever since
v1.8.0-rc0~155^2~7 (t9118: workaround inconsistency between SVN
versions, 2012-07-28) the test can survive that.
Tested with Debian Subversion 1.6.12dfsg-6 and 1.7.5-1 and r1395837
of Subversion trunk (1.8.x).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
These tests just want a bit-for-bit identical copy; they do not need
even -H (there is no symbolic link involved) nor -p (there is no
funny permission or ownership issues involved).
Just use "cp -R" instead.
Signed-off-by: Ben Walton <bdwalton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fsck test assumed too much on what kind of error it will
detect. The only important thing is the inconsistency is detected
as an error.
* jc/maint-t1450-fsck-order-fix:
t1450: the order the objects are checked is undefined
When using the {word,[...]} style of configuration for tags and branches,
it appears the intent is to only match whole path parts, since the words
in the {} pattern are meta-character quoted.
When the pattern word appears in the beginning or middle of the url,
it's matched completely, since the left side, pattern, and (non-empty)
right side are joined together with path separators.
However, when the pattern word appears at the end of the URL, the
right side is an empty pattern, and the resulting regex matches
more than just the specified pattern.
For example, if you specify something along the lines of
branches = branches/project/{release_1,release_2}
and your repository also contains "branches/project/release_1_2", you
will also get the release_1_2 branch. By restricting the match regex
with anchors, this is avoided.
Signed-off-by: Ammon Riley <ammon.riley@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This fixes `ambiguous redirect' error given by bash.
[ew: fix misspelled test name,
also eliminate space after ">>" to conform to guidelines]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This fixes a bug where git finds the incorrect merge parent. Consider a
repository with trunk, branch1 of trunk, and branch2 of branch1.
Without this change, git interprets a merge of branch2 into trunk as a
merge of branch1 into trunk.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Reviewed-by: Sam Vilain <sam@vilain.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Consider the case where you have trunk, branch1 of trunk, and branch2 of
branch1. trunk is merged back into branch2, and then branch2 is
reintegrated into trunk. The merge of branch2 into trunk will have
svn:mergeinfo property references to both branch1 and branch2. When
git-svn fetches the commit that merges branch2 (check_cherry_pick),
it is necessary to eliminate the merged contents of branch1 as well as
branch2, or else the merge will be incorrectly ignored as a cherry-pick.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Reviewed-by: Sam Vilain <sam@vilain.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Teach the commands from the "log" family the "--grep-reflog" option
to limit output by string that appears in the reflog entry when the
"--walk-reflogs" option is in effect.
* nd/grep-reflog:
revision: make --grep search in notes too if shown
log --grep-reflog: reject the option without -g
revision: add --grep-reflog to filter commits by reflog messages
grep: prepare for new header field filter
"gc --auto" notified the user that auto-packing has triggered even
under the "--quiet" option.
* tu/gc-auto-quiet:
silence git gc --auto --quiet output
When a tag T points at an object X that is of a type that is
different from what the tag records as, fsck should report it as an
error.
However, depending on the order X and T are checked individually,
the actual error message can be different. If X is checked first,
fsck remembers X's type and then when it checks T, it notices that T
records X as a wrong type (i.e. the complaint is about a broken tag
T). If T is checked first, on the other hand, fsck remembers that we
need to verify X is of the type tag records, and when it later
checks X, it notices that X is of a wrong type (i.e. the complaint
is about a broken object X).
The important thing is that fsck notices such an error and diagnoses
the issue on object X, but the test was expecting that we happen to
check objects in the order to make us detect issues with tag T, not
with object X. Remove this unwarranted assumption.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git submodule frotz" was not diagnosed as "frotz" being an unknown
subcommand to "git submodule"; the user instead got a complaint that
"git submodule status" was run with an unknown path "frotz".
* rr/maint-submodule-unknown-cmd:
submodule: if $command was not matched, don't parse other args
"git fetch" over http advertised that it supports "deflate", which
is much less common, and did not advertise more common "gzip" on its
Accept-Encoding header.
* sp/maint-http-enable-gzip:
Enable info/refs gzip decompression in HTTP client
The actual external command to run for mergetool backend can be
specified with difftool/mergetool.$name.cmd configuration
variables, but this mechanism was ignored for the backends we
natively support.
* da/mergetool-custom:
mergetool--lib: Allow custom commands to override built-ins
Send errors from "unpack-objects" and "index-pack" back to the "git
push" over the git and smart-http protocols, just like it is done
for a push over the ssh protocol.
* jk/receive-pack-unpack-error-to-pusher:
receive-pack: drop "n/a" on unpacker errors
receive-pack: send pack-processing stderr over sideband
receive-pack: redirect unpack-objects stdout to /dev/null
Running "git fetch" in a repository made with "git clone --single"
slurps all the branches, defeating the point of "--single".
* rt/maint-clone-single:
clone --single: limit the fetch refspec to fetched branch
* jc/maint-log-grep-all-match-1:
grep.c: make two symbols really file-scope static this time
t7810-grep: test --all-match with multiple --grep and --author options
t7810-grep: test interaction of multiple --grep and --author options
t7810-grep: test multiple --author with --all-match
t7810-grep: test multiple --grep with and without --all-match
t7810-grep: bring log --grep tests in common form
grep.c: mark private file-scope symbols as static
log: document use of multiple commit limiting options
log --grep/--author: honor --all-match honored for multiple --grep patterns
grep: show --debug output only once
grep: teach --debug option to dump the parse tree
Allows users to turn off smart-http when talking to dumb-only
servers.
* jk/smart-http-switch:
remote-curl: let users turn off smart http
remote-curl: rename is_http variable
Teach an option to edit the insn sheet to "git rebase -i".
* aw/rebase-i-edit-todo:
rebase -i: suggest using --edit-todo to fix an unknown instruction
rebase -i: Add tests for "--edit-todo"
rebase -i: Teach "--edit-todo" action
rebase -i: Refactor help messages for todo file
rebase usage: subcommands can not be combined with -i
Similar to --author/--committer which filters commits by author and
committer header fields. --grep-reflog adds a fake "reflog" header to
commit and a grep filter to search on that line.
All rules to --author/--committer apply except no timestamp stripping.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
grep supports only author and committer headers, which have the same
special treatment that later headers may or may not have. Check for
field type and only strip_timestamp() when the field is either author
or committer.
GREP_HEADER_FIELD_MAX is put in the grep_header_field enum to be
calculated automatically, correctly, as long as it's at the end of the
enum.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When --quiet is requested, gc --auto should not display messages unless
there is an error.
Signed-off-by: Tobias Ulmer <tobiasu@tmux.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We correctly handle completion items with spaces just fine,
since we pass the lists around with newline delimiters.
However, we do not handle filenames with shell
metacharacters, as "compgen -W" performs expansion on the
list we give it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We were not testing ref or tree completion at all. Let's
give them even basic sanity checks to avoid regressions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The malloc checks in tests are currently disabled. Actually evaluate
the variable for turning them off and enable them if it's unset.
Also use this opportunity to give it the more descriptive and
consistent name TEST_NO_MALLOC_CHECK.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git submodule" command DWIMs the command line and assumes a
unspecified action word for 'status' action. This is a UI mistake
that leads to a confusing behaviour. A mistyped command name is
instead treated as a request for 'status' of the submodule with that
name, e.g.
$ git submodule show
error: pathspec 'show' did not match any file(s) known to git.
Did you forget to 'git add'?
Stop DWIMming an unknown or mistyped subcommand name as pathspec
given to unspelled "status" subcommand. "git submodule" without any
argument is still interpreted as "git submodule status", but its
value is questionable.
Adjust t7400 to match, and stop advertising the default subcommand
being 'status' which does not help much in practice, other than
promoting laziness and confusion.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only the first test t0000 in the test suite made sure we have built
Git to be tested; move the check to test-lib so that it applies to
all tests equally.
* rr/test-make-sure-we-have-git:
t/test-lib: make sure Git has already been built
Run our test scripts with MALLOC_CHECK_ and MALLOC_PERTURB_, the
built-in memory access checking facility GNU libc has.
* ep/malloc-check-perturb:
MALLOC_CHECK: various clean-ups
Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
When "git am" is fed an input that has multiple "Content-type: ..."
header, it did not grok charset= attribute correctly.
* jc/maint-mailinfo-mime-attr:
mailinfo: do not concatenate charset= attribute values from mime headers
The codepath for handling "--tee" ends up relaunching the test
script under a shell, and that one has to be a Bourne. But we
incorrectly used $SHELL, which could be a non-Bourne (e.g. zsh or
csh); we have the Makefile variable $SHELL_PATH for exactly that,
so use it instead.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow users to override the default commands provided by the
mergetools/* scriptlets.
Users occasionally run into problems where they expect to be
able to override the built-in tool names. The documentation
does not explicitly mention that built-ins cannot be overridden,
so it's easy to assume that it should work.
Lift this restriction so that built-in tools are handled the
same way as user-configured tools. Add tests to guarantee this
behavior.
A nice benefit of this change is that it protects users from
having future versions of git trump their custom configuration
with a new built-in tool.
C.f.:
http://stackoverflow.com/questions/7435002/mergetool-from-gitconfig-being-ignoredhttp://thread.gmane.org/gmane.comp.version-control.msysgit/13188http://thread.gmane.org/gmane.comp.version-control.git/148267
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even during a conflicted merge, "git blame $path" always meant to
blame uncommitted changes to the "working tree" version; make it
more useful by showing cleanly merged parts as coming from the other
branch that is being merged.
This incidentally fixes an unrelated problem on a case insensitive
filesystem, where "git blame MAKEFILE" run in a history that has
"Makefile" but not "MAKEFILE" did not say "No such file MAKEFILE in
HEAD" but pretended as if "MAKEFILE" was a newly added file.
* jc/maint-blame-no-such-path:
blame: allow "blame file" in the middle of a conflicted merge
blame $path: avoid getting fooled by case insensitive filesystems
"git fetch --all", when passed "--no-tags", did not honor the
"--no-tags" option while fetching from individual remotes (the same
issue existed with "--tags", but combination "--all --tags" makes
much less sense than "--all --no-tags").
* dj/fetch-all-tags:
fetch --all: pass --tags/--no-tags through to each remote
submodule: use argv_array instead of hand-building arrays
fetch: use argv_array instead of hand-building arrays
argv-array: fix bogus cast when freeing array
argv-array: add pop function
Usually there is no need for users to specify whether an
http remote is smart or dumb; the protocol is designed so
that a single initial request is made, and the client can
determine the server's capability from the response.
However, some misconfigured dumb-only servers may not like
the initial request by a smart client, as it contains a
query string. Until recently, commit 703e6e7 worked around
this by making a second request. However, that commit was
recently reverted due to its side effect of masking the
initial request's error code.
Since git has had that workaround for several years, we
don't know exactly how many such misconfigured servers are
out there. The reversion of 703e6e7 assumes they are rare
enough not to worry about. Still, that reversion leaves
somebody who does run into such a server with no escape
hatch at all. Let's give them an environment variable they
can tweak to perform the "dumb" request.
This is intentionally not a documented interface. It's
overly simple and is really there for debugging in case
somebody does complain about git not working with their
server. A real user-facing interface would entail a
per-remote or per-URL config variable.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output from git push currently looks like this:
$ git push dest HEAD
fatal: [some message from index-pack]
error: unpack failed: index-pack abnormal exit
To dest
! [remote rejected] HEAD -> master (n/a (unpacker error))
That n/a is meant to be "the per-ref status is not
available" but the nested parentheses just make it look
ugly. Let's turn the final line into just:
! [remote rejected] HEAD -> master (unpacker error)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After running "git clone --single", the resulting repository has the
usual default "+refs/heads/*:refs/remotes/origin/*" wildcard fetch
refspec installed, which means that a subsequent "git fetch" will
end up grabbing all the other branches.
Update the fetch refspec to cover only the singly cloned ref instead
to correct this.
That means:
If "--single" is used without "--branch" or "--mirror", the
fetch refspec covers the branch on which remote's HEAD points to.
If "--single" is used with "--branch", it'll cover only the branch
specified in the "--branch" option.
If "--single" is combined with "--mirror", then it'll cover all
refs of the cloned repository.
If "--single" is used with "--branch" that specifies a tag, then
it'll cover only the ref for this tag.
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some HTTP servers try to use gzip compression on the /info/refs
request to save transfer bandwidth. Repositories with many tags
may find the /info/refs request can be gzipped to be 50% of the
original size due to the few but often repeated bytes used (hex
SHA-1 and commonly digits in tag names).
For most HTTP requests enable "Accept-Encoding: gzip" ensuring
the /info/refs payload can use this encoding format.
Only request gzip encoding from servers. Although deflate is
supported by libcurl, most servers have standardized on gzip
encoding for compression as that is what most browsers support.
Asking for deflate increases request sizes by a few bytes, but is
unlikely to ever be used by a server.
Disable the Accept-Encoding header on probe RPCs as response bodies
are supposed to be exactly 4 bytes long, "0000". The HTTP headers
requesting and indicating compression use more space than the data
transferred in the body.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
