summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2016-12-05t3600: remove useless redirectLibravatar Stefan Beller1-1/+1
In the next line the `actual` is overwritten again, so no need to redirect the output of checkout into that file. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07rm: better document side effects when removing a submoduleLibravatar Jens Lehmann1-0/+16
The "Submodules" section of the "git rm" documentation mentions what will happen when a submodule with a gitfile gets removed with newer git. But it doesn't talk about what happens when the user changes between commits before and after the removal, which does not remove the submodule from the work tree like using the rm command did the first time. Explain what happens and what the user has to do manually to fix that in the new BUGS section. Also document this behavior in a new test. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07mv: better document side effects when moving a submoduleLibravatar Jens Lehmann1-0/+21
The "Submodules" section of the "git mv" documentation mentions what will happen when a submodule with a gitfile gets moved with newer git. But it doesn't talk about what happens when the user changes between commits before and after the move, which does not update the work tree like using the mv command did the first time. Explain what happens and what the user has to do manually to fix that in the new BUGS section. Also document this behavior in a new test. Reported-by: George Papanikolaou <g3orge.app@gmail.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-27Merge branch 'jk/name-pack-after-byte-representation'Libravatar Junio C Hamano1-2/+2
Two packfiles that contain the same set of objects have traditionally been named identically, but that made repacking a repository that is already fully packed without any cruft with a different packing parameter cumbersome. Update the convention to name the packfile after the bytestream representation of the data, not after the set of objects in it. * jk/name-pack-after-byte-representation: pack-objects doc: treat output filename as opaque pack-objects: name pack files after trailer hash sha1write: make buffer const-correct
2013-12-27Merge branch 'tg/diff-no-index-refactor'Libravatar Junio C Hamano2-0/+48
"git diff ../else/where/A ../else/where/B" when ../else/where is clearly outside the repository, and "git diff --no-index A B", do not have to look at the index at all, but we used to read the index unconditionally. * tg/diff-no-index-refactor: diff: avoid some nesting diff: add test for --no-index executed outside repo diff: don't read index when --no-index is given diff: move no-index detection to builtin/diff.c
2013-12-27Merge branch 'zk/difftool-counts'Libravatar Junio C Hamano1-0/+13
Show the total number of paths and the number of paths shown so far when "git difftool" prompts to launch an external diff tool, which would give users some sense of progress. * zk/difftool-counts: diff.c: fix some recent whitespace style violations difftool: display the number of files in the diff queue in the prompt
2013-12-27Merge branch 'jk/cat-file-regression-fix'Libravatar Junio C Hamano1-0/+22
"git cat-file --batch=", an admittedly useless command, did not behave very well. * jk/cat-file-regression-fix: cat-file: handle --batch format with missing type/size cat-file: pass expand_data to print_object_or_die
2013-12-27Merge branch 'jk/pull-rebase-using-fork-point'Libravatar Junio C Hamano1-2/+4
* jk/pull-rebase-using-fork-point: rebase: use reflog to find common base with upstream pull: use merge-base --fork-point when appropriate
2013-12-27Merge branch 'jk/rev-parse-double-dashes'Libravatar Junio C Hamano1-0/+24
"git rev-parse <revs> -- <paths>" did not implement the usual disambiguation rules the commands in the "git log" family used in the same way. * jk/rev-parse-double-dashes: rev-parse: be more careful with munging arguments rev-parse: correctly diagnose revision errors before "--"
2013-12-27Merge branch 'jc/push-refmap'Libravatar Junio C Hamano1-0/+75
Make "git push origin master" update the same ref that would be updated by our 'master' when "git push origin" (no refspecs) is run while the 'master' branch is checked out, which makes "git push" more symmetric to "git fetch" and more usable for the triangular workflow. * jc/push-refmap: push: also use "upstream" mapping when pushing a single ref push: use remote.$name.push as a refmap builtin/push.c: use strbuf instead of manual allocation
2013-12-17Merge branch 'tb/clone-ssh-with-colon-for-port'Libravatar Junio C Hamano2-21/+198
Be more careful when parsing remote repository URL given in the scp-style host:path notation. * tb/clone-ssh-with-colon-for-port: git_connect(): use common return point connect.c: refactor url parsing git_connect(): refactor the port handling for ssh git fetch: support host:/~repo t5500: add test cases for diag-url git fetch-pack: add --diag-url git_connect: factor out discovery of the protocol and its parts git_connect: remove artificial limit of a remote command t5601: add tests for ssh t5601: remove clear_ssh, refactor setup_ssh_wrapper
2013-12-17Merge branch 'jl/commit-v-strip-marker'Libravatar Junio C Hamano1-1/+27
"git commit -v" appends the patch to the log message before editing, and then removes the patch when the editor returned control. However, the patch was not stripped correctly when the first modified path was a submodule. * jl/commit-v-strip-marker: commit -v: strip diffs and submodule shortlogs from the commit message
2013-12-17Merge branch 'mm/mv-file-to-no-such-dir-with-slash'Libravatar Junio C Hamano1-0/+29
* mm/mv-file-to-no-such-dir-with-slash: mv: let 'git mv file no-such-dir/' error out
2013-12-17Merge branch 'fc/trivial'Libravatar Junio C Hamano2-3/+1
* fc/trivial: remote: fix status with branch...rebase=preserve fetch: add missing documentation t: trivial whitespace cleanups abspath: trivial style fix
2013-12-17Merge branch 'jk/t5000-gzip-simplify'Libravatar Junio C Hamano1-16/+4
Test fix. * jk/t5000-gzip-simplify: t5000: simplify gzip prerequisite checks
2013-12-16diff: add test for --no-index executed outside repoLibravatar Thomas Gummerer1-0/+11
470faf9 diff: move no-index detection to builtin/diff.c breaks the error message for "git diff --no-index", when the command is executed outside of a git repository and the wrong number of arguments are given. 6df5762 diff: don't read index when --no-index is given fixes the problem. Add a test to guard against similar breakages in the future. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12Merge branch 'jn/scripts-updates'Libravatar Junio C Hamano32-41/+70
* jn/scripts-updates: remove #!interpreter line from shell libraries test: replace shebangs with descriptions in shell libraries test: make FILEMODE a lazy prereq contrib: remove git-p4import mark contributed hooks executable mark perl test scripts executable mark Windows build scripts executable
2013-12-12Merge branch 'jk/remove-deprecated'Libravatar Junio C Hamano3-25/+5
* jk/remove-deprecated: stop installing git-tar-tree link peek-remote: remove deprecated alias of ls-remote lost-found: remove deprecated command tar-tree: remove deprecated command repo-config: remove deprecated alias for "git config"
2013-12-12Merge branch 'tr/config-multivalue-lift-max'Libravatar Junio C Hamano1-0/+64
* tr/config-multivalue-lift-max: config: arbitrary number of matches for --unset and --replace-all
2013-12-12Merge branch 'mh/fetch-tags-in-addition-to-normal-refs'Libravatar Junio C Hamano5-13/+148
The "--tags" option to "git fetch" used to be literally a synonym to a "refs/tags/*:refs/tags/*" refspec, which meant that (1) as an explicit refspec given from the command line, it silenced the lazy "git fetch" default that is configured, and (2) also as an explicit refspec given from the command line, it interacted with "--prune" to remove any tag that the remote we are fetching from does not have. This demotes it to an option; with it, we fetch all tags in addition to what would be fetched without the option, and it does not interact with the decision "--prune" makes to see what remote-tracking refs the local has are missing the remote counterpart. * mh/fetch-tags-in-addition-to-normal-refs: (23 commits) fetch: improve the error messages emitted for conflicting refspecs handle_duplicate(): mark error message for translation ref_remote_duplicates(): extract a function handle_duplicate() ref_remove_duplicates(): simplify loop logic t5536: new test of refspec conflicts when fetching ref_remove_duplicates(): avoid redundant bisection git-fetch.txt: improve description of tag auto-following fetch-options.txt: simplify ifdef/ifndef/endif usage fetch, remote: properly convey --no-prune options to subprocesses builtin/remote.c:update(): use struct argv_array builtin/remote.c: reorder function definitions query_refspecs(): move some constants out of the loop fetch --prune: prune only based on explicit refspecs fetch --tags: fetch tags *in addition to* other stuff fetch: only opportunistically update references based on command line get_expanded_map(): avoid memory leak get_expanded_map(): add docstring builtin/fetch.c: reorder function definitions get_ref_map(): rename local variables api-remote.txt: correct section "struct refspec" ...
2013-12-12diff: don't read index when --no-index is givenLibravatar Thomas Gummerer2-0/+37
git diff --no-index ... currently reads the index, during setup, when calling gitmodules_config(). This results in worse performance when the index is not actually needed. This patch avoids calling gitmodules_config() when the --no-index option is given. The times for executing "git diff --no-index" in the WebKit repository are improved as follows: Test HEAD~3 HEAD ------------------------------------------------------------------ 4001.1: diff --no-index 0.24(0.15+0.09) 0.01(0.00+0.00) -95.8% An additional improvement of this patch is that "git diff --no-index" no longer breaks when the index file is corrupt, which makes it possible to use it for investigating the broken repository. To improve the possible usage as investigation tool for broken repositories, setup_git_directory_gently() is also not called when the --no-index option is given. Also add a test to guard against future breakages, and a performance test to show the improvements. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12cat-file: handle --batch format with missing type/sizeLibravatar Jeff King1-0/+22
Commit 98e2092 taught cat-file to stream blobs with --batch, which requires that we look up the object type before loading it into memory. As a result, we now print the object header from information in sha1_object_info, and the actual contents from the read_sha1_file. We double-check that the information we printed in the header matches the content we are about to show. Later, commit 93d2a60 allowed custom header lines for --batch, and commit 5b08640 made type lookups optional. As a result, specifying a header line without the type or size means that we will not look up those items at all. This causes our double-checking to erroneously die with an error; we think the type or size has changed, when in fact it was simply left at "0". For the size, we can fix this by only doing the consistency double-check when we have retrieved the size via sha1_object_info. In the case that we have not retrieved the value, that means we also did not print it, so there is nothing for us to check that we are consistent with. We could do the same for the type. However, besides our consistency check, we also care about the type in deciding whether to stream or not. So instead of handling the case where we do not know the type, this patch instead makes sure that we always trigger a type lookup when we are printing, so that even a format without the type will stream as we would in the normal case. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10rebase: use reflog to find common base with upstreamLibravatar John Keeping1-2/+4
Commit 15a147e (rebase: use @{upstream} if no upstream specified, 2011-02-09) says: Make it default to 'git rebase @{upstream}'. That is also what 'git pull [--rebase]' defaults to, so it only makes sense that 'git rebase' defaults to the same thing. but that isn't actually the case. Since commit d44e712 (pull: support rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually chosen the most recent reflog entry which is an ancestor of the current branch if it can find one. Add a '--fork-point' argument to git-rebase that can be used to trigger this behaviour. This option is turned on by default if no non-option arguments are specified on the command line, otherwise we treat an upstream specified on the command-line literally. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09connect.c: refactor url parsingLibravatar Torsten Bögershausen2-0/+15
Make the function is_local() in transport.c public, rename it into url_is_local_not_ssh() and use it in both transport.c and connect.c Use a protocol "local" for URLs for the local file system. One note about using file:// under Windows: The (absolute) path on Unix like system typically starts with "/". When the host is empty, it can be omitted, so that a shell scriptlet url=file://$pwd will give a URL like "file:///home/user/repo". Windows does not have the same concept of a root directory located in "/". When parsing the URL allow "file://C:/user/repo" (even if RFC1738 indicates that "file:///C:/user/repo" should be used). Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09git_connect(): refactor the port handling for sshLibravatar Torsten Bögershausen2-15/+4
Use get_host_and_port() even for ssh. Remove the variable port git_connect(), and simplify parse_connect_url() Use only one return point in git_connect(), doing the free() and return conn. t5601 had 2 corner test cases which now pass. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09git fetch: support host:/~repoLibravatar Torsten Bögershausen2-10/+26
The documentation (in urls.txt) says that "ssh://host:/~repo", "host:/~repo" or "host:~repo" specify the repository "repo" in the home directory at "host". This has not been working for "host:/~repo". Before commit 356bec "Support [address] in URLs", the comparison "url != hostname" could be used to determine if the URL had a scheme or not: "ssh://host/host" != "host". However, after 356bec "[::1]" was converted into "::1", yielding url != hostname as well. To fix this regression, don't use "if (url != hostname)", but look at the separator instead. Rename the variable "c" into "separator" to make it easier to read. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09t5500: add test cases for diag-urlLibravatar Torsten Bögershausen1-0/+59
Add test cases using git fetch-pack --diag-url: - parse out host and path for URLs with a scheme (git:// file:// ssh://) - parse host names embedded by [] correctly - extract the port number, if present - separate URLs like "file" (which are local) from URLs like "host:repo" which should use ssh Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09t: trivial whitespace cleanupsLibravatar Felipe Contreras2-3/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09rev-parse: correctly diagnose revision errors before "--"Libravatar Jeff King1-0/+24
Rev-parse understands that a "--" may separate revisions and filenames, and that anything after the "--" is taken as-is. However, it does not understand that anything before the token must be a revision (which is the usual rule implemented by the setup_revisions parser). Since rev-parse prefers revisions to files when parsing before the "--", we end up with the correct result (if such an argument is a revision, we parse it as one, and if it is not, it is an error either way). However, we misdiagnose the errors: $ git rev-parse foobar -- >/dev/null fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ >foobar $ git rev-parse foobar -- >/dev/null fatal: bad flag '--' used after filename In both cases, we should know that the real error is that "foobar" is meant to be a revision, but could not be resolved. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-06difftool: display the number of files in the diff queue in the promptLibravatar Zoltan Klinger1-0/+13
When --prompt option is set, git-difftool displays a prompt for each modified file to be viewed in an external diff program. At that point, it could be useful to display a counter and the total number of files in the diff queue. Below is the current difftool prompt for the first of 5 modified files: Viewing: 'diff.c' Launch 'vimdiff' [Y/n]: Consider the modified prompt: Viewing (1/5): 'diff.c' Launch 'vimdiff' [Y/n]: The current GIT_EXTERNAL_DIFF mechanism does not tell the number of paths in the diff queue nor the current counter. To make this "counter/total" info available for GIT_EXTERNAL_DIFF programs without breaking existing ones by doing the following: - Keep track of the number of paths shown so far in diff_options; - Export two new environment variables from run_external_diff() to show the total number of paths (from diff_queue_struct) and the current value of the counter (from diff_options); and - Update git-difftool--helper to use these two environment variables. Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-06config: arbitrary number of matches for --unset and --replace-allLibravatar Thomas Rast1-0/+64
git-config used a static match array to hold the matches we want to unset/replace when using --unset or --replace-all. Use a variable-sized array instead. This in particular fixes the symptoms git-svn had when storing large numbers of svn-remote.*.added-placeholder entries in the config file. While the tests are rather more paranoid than just --unset and --replace-all, the other operations already worked. Indeed git-svn's usage only breaks the first time *after* creating so many entries, when it wants to unset and re-add them all. Reported-by: Jess Hottenstein <jess.hottenstein@gmail.com> Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-06Merge branch 'jk/remove-experimental-loose-object-support'Libravatar Junio C Hamano18-69/+0
* jk/remove-experimental-loose-object-support: drop support for "experimental" loose objects
2013-12-06Merge branch 'nd/magic-pathspec'Libravatar Junio C Hamano1-0/+6
"git diff -- ':(icase)makefile'" were rejected unnecessarily. This needs to be merged to 'maint' later. * nd/magic-pathspec: diff: restrict pathspec limitations to diff b/f case only
2013-12-06Merge branch 'rr/for-each-ref-decoration'Libravatar Junio C Hamano1-13/+56
Add a few formatting directives to "git for-each-ref --format=...", to paint them in color, etc. * rr/for-each-ref-decoration: for-each-ref: avoid color leakage for-each-ref: introduce %(color:...) for color for-each-ref: introduce %(upstream:track[short]) for-each-ref: introduce %(HEAD) asterisk marker t6300 (for-each-ref): don't hardcode SHA-1 hexes t6300 (for-each-ref): clearly demarcate setup
2013-12-06Merge branch 'rh/remote-hg-bzr-updates'Libravatar Junio C Hamano1-0/+4
Updates to remote-bzr and remote-hg in contrib. * rh/remote-hg-bzr-updates: remote-bzr, remote-hg: fix email address regular expression test-hg.sh: help user correlate verbose output with email test test-hg.sh: fix duplicate content strings in author tests test-hg.sh: avoid obsolete 'test' syntax test-hg.sh: eliminate 'local' bashism test-bzr.sh, test-hg.sh: prepare for change to push.default=simple test-bzr.sh, test-hg.sh: allow running from any dir test-lib.sh: convert $TEST_DIRECTORY to an absolute path
2013-12-05pack-objects: name pack files after trailer hashLibravatar Jeff King1-2/+2
Our current scheme for naming packfiles is to calculate the sha1 hash of the sorted list of objects contained in the packfile. This gives us a unique name, so we are reasonably sure that two packs with the same name will contain the same objects. It does not, however, tell us that two such packs have the exact same bytes. This makes things awkward if we repack the same set of objects. Due to run-to-run variations, the bytes may not be identical (e.g., changed zlib or git versions, different source object reuse due to new packs in the repository, or even different deltas due to races during a multi-threaded delta search). In theory, this could be helpful to a program that cares that the packfile contains a certain set of objects, but does not care about the particular representation. In practice, no part of git makes use of that, and in many cases it is potentially harmful. For example, if a dumb http client fetches the .idx file, it must be sure to get the exact .pack that matches it. Similarly, a partial transfer of a .pack file cannot be safely resumed, as the actual bytes may have changed. This could also affect a local client which opened the .idx and .pack files, closes the .pack file (due to memory or file descriptor limits), and then re-opens a changed packfile. In all of these cases, git can detect the problem, as we have the sha1 of the bytes themselves in the pack trailer (which we verify on transfer), and the .idx file references the trailer from the matching packfile. But it would be simpler and more efficient to actually get the correct bytes, rather than noticing the problem and having to restart the operation. This patch simply uses the pack trailer sha1 as the pack name. It should be similarly unique, but covers the exact representation of the objects. Other parts of git should not care, as the pack name is returned by pack-objects and is essentially opaque. One test needs to be updated, because it actually corrupts a pack and expects that re-packing the corrupted bytes will use the same name. It won't anymore, but we can easily just use the name that pack-objects hands back. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05commit -v: strip diffs and submodule shortlogs from the commit messageLibravatar Jens Lehmann1-1/+27
When using the '-v' option of "git commit" the diff added to the commit message temporarily for editing is stripped off after the user exited the editor by searching for "\ndiff --git " and truncating the commmit message there if it is found. But this approach has two problems: - when the commit message itself contains a line starting with "diff --git" it will be truncated there prematurely; and - when the "diff.submodule" setting is set to "log", the diff may start with "Submodule <hash1>..<hash2>", which will be left in the commit message while it shouldn't. Fix that by introducing a special scissor separator line starting with the comment character ('#' or the core.commentChar config if set) followed by two lines describing what it is for. The scissor line - which will not be translated - is used to reliably detect the start of the diff so it can be chopped off from the commit message, no matter what the user enters there. Turn a known test failure fixed by this change into a successful test; also add one for a diff starting with a submodule log and another one for proper handling of the comment char. Reported-by: Ari Pollak <ari@debian.org> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05Sync with 1.8.5Libravatar Junio C Hamano2-11/+20
2013-12-05Merge branch 'jl/submodule-update-retire-orig-flags'Libravatar Junio C Hamano1-0/+11
Code clean-up. * jl/submodule-update-retire-orig-flags: submodule update: remove unnecessary orig_flags variable
2013-12-05Merge branch 'sb/sha1-loose-object-info-check-existence'Libravatar Junio C Hamano1-0/+6
"git cat-file --batch-check=ok" did not check the existence of the named object. * sb/sha1-loose-object-info-check-existence: sha1_loose_object_info(): do not return success on missing object
2013-12-05Merge branch 'jk/two-way-merge-corner-case-fix'Libravatar Junio C Hamano2-89/+104
Fix a rather longstanding corner-case bug in twoway "reset to there" merge, which is most often seen in "git am --abort". * jk/two-way-merge-corner-case-fix: t1005: add test for "read-tree --reset -u A B" t1005: reindent unpack-trees: fix "read-tree -u --reset A B" with conflicted index
2013-12-05Merge branch 'jc/ref-excludes'Libravatar Junio C Hamano1-0/+54
People often wished a way to tell "git log --branches" (and "git log --remotes --not --branches") to exclude some local branches from the expansion of "--branches" (similarly for "--tags", "--all" and "--glob=<pattern>"). Now they have one. * jc/ref-excludes: rev-parse: introduce --exclude=<glob> to tame wildcards rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API rev-list --exclude: tests document --exclude option revision: introduce --exclude=<glob> to tame wildcards
2013-12-05Merge branch 'nv/parseopt-opt-arg'Libravatar Junio C Hamano1-3/+39
Enhance "rev-parse --parseopt" mode to help parsing options with an optional parameter. * nv/parseopt-opt-arg: rev-parse --parseopt: add the --stuck-long mode Use the word 'stuck' instead of 'sticked'
2013-12-05Merge branch 'jc/merge-base-reflog'Libravatar Junio C Hamano1-0/+28
Code the logic in "pull --rebase" that figures out a fork point from reflog entries in C. * jc/merge-base-reflog: merge-base: teach "--fork-point" mode merge-base: use OPT_CMDMODE and clarify the command line parsing
2013-12-05Merge branch 'ak/submodule-foreach-quoting'Libravatar Junio C Hamano1-0/+9
A behavior change, but a worthwhile one: "git submodule foreach" was treating its arguments as part of a single command to be concatenated and passed to a shell, making writing buggy scripts too easy. This patch preserves the old "just pass it to the shell" behavior when a single argument is passed to 'git submodule foreach' and moves to a new "skip the shell and use the arguments passed unmolested" behavior when more than one argument is passed. The old behavior (always concatenating and passing to the shell) was similar to the 'ssh' command, while the new behavior (switching on the number of arguments) is what 'xterm -e' does. May need more thought to make sure this change is advertised well so that scripts that used multiple arguments but added their own extra layer of quoting are not broken. * ak/submodule-foreach-quoting: submodule foreach: skip eval for more than one argument
2013-12-04t5000: simplify gzip prerequisite checksLibravatar Jeff King1-16/+4
In t5000, we test the built-in ".tar.gz" config for git-archive. To make our tests portable, we check that we have a way to both gzip and gunzip, and we respected environment variables to point to alternate commands for doing these operations. However, the $GZIP variable did not actually do anything, as changing it would not affect the baked-in value in archive-tar.c. Moreover, setting the variable $GZIP influences gzip itself. From the gzip man page: The environment variable GZIP can hold a set of default options for gzip. These options are interpreted first and can be overwritten by explicit command line parameters. We could rename this variable, and use it to set up custom config (or even have a Makefile knob to affect the built binary), but it is not worth the trouble; nobody has ever reported a problem with the baked-in default, and they can always change it via config if they need to. Let's just drop the variable and use "gzip" in the test (keeping the prerequisite, of course). While we're at it, we can drop the GUNZIP variable and prerequisite; it uses "gzip -d", so if we have GZIP, we will have both. We can also use test_lazy_prereq for the gzip prerequisite, which is simpler and behaves more consistently with the rest of git (e.g., by making output available when the test is run with "-v"). Noticed-by: Christian Hesse <mail@eworm.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04t5601: add tests for sshLibravatar Torsten Bögershausen1-1/+99
Add more tests testing all the combinations: -IPv4 or IPv6 -path starting with "/" or with "/~" -with and without the ssh:// scheme Some tests fail; they need updates in connect.c Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04t5601: remove clear_ssh, refactor setup_ssh_wrapperLibravatar Torsten Bögershausen1-20/+20
Commit 8d3d28f5 added test cases for URLs which should be ssh. Remove the function clear_ssh, use test_when_finished to clean up. Introduce the function setup_ssh_wrapper, which could be factored out together with expect_ssh. Tighten one test and use "foo:bar" instead of "./foo:bar", Helped-by: Jeff King <peff@peff.net> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04push: also use "upstream" mapping when pushing a single refLibravatar Junio C Hamano1-0/+30
When the user is using the 'upstream' mode, these commands: $ git push $ git push origin would find the 'upstream' branch for the current branch, and then push the current branch to update it. However, pushing a single branch explicitly, i.e. $ git push origin $(git symbolic-ref --short HEAD) would not go through the same ref mapping process, and ends up updating the branch at 'origin' of the same name, which may not necessarily be the upstream of the branch being pushed. In the spirit similar to the previous one, map a colon-less refspec using the upstream mapping logic. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04push: use remote.$name.push as a refmapLibravatar Junio C Hamano1-0/+45
Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>