summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2015-03-05Merge branch 'mh/refs-have-new'Libravatar Junio C Hamano1-0/+30
Simplify the ref transaction API around how "the ref should be pointing at this object" is specified. * mh/refs-have-new: refs.h: remove duplication in function docstrings update_ref(): improve documentation ref_transaction_verify(): new function to check a reference's value ref_transaction_delete(): check that old_sha1 is not null_sha1 ref_transaction_create(): check that new_sha1 is valid commit: avoid race when creating orphan commits commit: add tests of commit races ref_transaction_delete(): remove "have_old" parameter ref_transaction_update(): remove "have_old" parameter struct ref_update: move "have_old" into "flags" refs.c: change some "flags" to "unsigned int" refs: remove the gap in the REF_* constant values refs: move REF_DELETING to refs.c
2015-03-03Merge branch 'jk/daemon-interpolate'Libravatar Junio C Hamano1-0/+27
The "interpolated-path" option of "git daemon" inserted any string client declared on the "host=" capability request without checking. Sanitize and limit %H and %CH to a saner and a valid DNS name. * jk/daemon-interpolate: daemon: sanitize incoming virtual hostname t5570: test git-daemon's --interpolated-path option git_connect: let user override virtual-host we send to daemon
2015-03-03Merge branch 'km/send-email-getopt-long-workarounds'Libravatar Junio C Hamano1-5/+5
Even though we officially haven't dropped Perl 5.8 support, the Getopt::Long package that came with it does not support "--no-" prefix to negate a boolean option; manually add support to help people with older Getopt::Long package. * km/send-email-getopt-long-workarounds: git-send-email.perl: support no- prefix with older GetOptions
2015-03-03Merge branch 'jc/apply-beyond-symlink'Libravatar Junio C Hamano2-0/+247
"git apply" was not very careful about reading from, removing, updating and creating paths outside the working tree (under --index/--cached) or the current directory (when used as a replacement for GNU patch). * jc/apply-beyond-symlink: apply: do not touch a file beyond a symbolic link apply: do not read from beyond a symbolic link apply: do not read from the filesystem under --index apply: reject input that touches outside the working area
2015-02-25Merge branch 'jk/sanity'Libravatar Junio C Hamano4-9/+42
The tests that wanted to see that file becomes unreadable after running "chmod a-r file", and the tests that wanted to make sure it is not run as root, we used "can we write into the / directory?" as a cheap substitute, but on some platforms that is not a good heuristics. The tests and their prerequisites have been updated to check what they really require. * jk/sanity: test-lib.sh: set prerequisite SANITY by testing what we really need tests: correct misuses of POSIXPERM t/lib-httpd: switch SANITY check for NOT_ROOT
2015-02-22Merge branch 'jk/prune-mtime'Libravatar Junio C Hamano1-0/+8
In v2.2.0, we broke "git prune" that runs in a repository that borrows from an alternate object store. * jk/prune-mtime: sha1_file: fix iterating loose alternate objects for_each_loose_file_in_objdir: take an optional strbuf path
2015-02-22Merge branch 'ps/submodule-sanitize-path-upon-add'Libravatar Junio C Hamano1-0/+17
"git submodule add" failed to squash "path/to/././submodule" to "path/to/submodule". * ps/submodule-sanitize-path-upon-add: git-submodule.sh: fix '/././' path normalization
2015-02-22Merge branch 'ab/merge-file-prefix'Libravatar Junio C Hamano1-1/+2
"git merge-file" did not work correctly in a subdirectory. * ab/merge-file-prefix: merge-file: correctly open files when in a subdir
2015-02-18Merge branch 'jk/config-no-ungetc-eof'Libravatar Junio C Hamano1-0/+9
Reading configuration from a blob object, when it ends with a lone CR, use to confuse the configuration parser. * jk/config-no-ungetc-eof: config_buf_ungetc: warn when pushing back a random character config: do not ungetc EOF
2015-02-18Merge branch 'ch/new-gpg-drops-rfc-1991'Libravatar Junio C Hamano2-0/+58
Older GnuPG implementations may not correctly import the keyring material we prepare for the tests to use. * ch/new-gpg-drops-rfc-1991: t/lib-gpg: sanity-check that we can actually sign t/lib-gpg: include separate public keys in keyring.gpg
2015-02-18Merge branch 'ye/http-accept-language'Libravatar Junio C Hamano1-0/+42
Using environment variable LANGUAGE and friends on the client side, HTTP-based transports now send Accept-Language when making requests. * ye/http-accept-language: http: add Accept-Language header if possible
2015-02-17daemon: sanitize incoming virtual hostnameLibravatar Jeff King1-0/+11
We use the daemon_avoid_alias function to make sure that the pathname the user gives us is sane. However, after applying that check, we might then interpolate the path using a string given by the server admin, but which may contain more untrusted data from the client. We should be sure to sanitize this data, as well. We cannot use daemon_avoid_alias here, as it is more strict than we need in requiring a leading '/'. At the same time, we can be much more strict here. We are interpreting a hostname, which should not contain slashes or excessive runs of dots, as those things are not allowed in DNS names. Note that in addition to cleansing the hostname field, we must check the "canonical hostname" (%CH) as well as the port (%P), which we take as a raw string. For the canonical hostname, this comes from an actual DNS lookup on the accessed IP, which makes it a much less likely vector for problems. But it does not hurt to sanitize it in the same way. Unfortunately we cannot test this case easily, as it would involve a custom hostname lookup. We do not need to check %IP, as it comes straight from inet_ntop, so must have a sane form. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-17t5570: test git-daemon's --interpolated-path optionLibravatar Jeff King1-0/+16
We did not test this at all; let's just give a basic sanity check that we can find a path based on virtual hosting, and that the downcase canonicalization works. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-17commit: avoid race when creating orphan commitsLibravatar Michael Haggerty1-1/+1
If HEAD doesn't point at anything during the initial check, then we should make sure that it *still* doesn't point at anything when we are ready to update the reference. Otherwise, another process might commit while we are working (e.g., while we are waiting for the user to edit the commit message) and we will silently overwrite it. This fixes a failing test in t7516. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-17commit: add tests of commit racesLibravatar Michael Haggerty1-0/+30
Committing involves the following steps: 1. Determine the current value of HEAD (if any). 2. Create the new commit object. 3. Update HEAD. Please note that step 2 can take arbitrarily long, because it might involve the user editing a commit message. If a second process sneaks in a commit during step 2, then the first commit process should fail. This is usually done correctly, because step 3 verifies that HEAD still points at the same commit that it pointed to during step 1. However, if there is a race when creating an *orphan* commit, then the test in step 3 is skipped. Add tests for proper handling of such races. One of the new tests fails. It will be fixed in a moment. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-17Merge branch 'jc/t4122-use-test-write-lines'Libravatar Junio C Hamano1-9/+2
* jc/t4122-use-test-write-lines: t4122: use test_write_lines from test-lib-functions
2015-02-17Merge branch 'jk/dumb-http-idx-fetch-fix'Libravatar Junio C Hamano1-0/+18
A broken pack .idx file in the receiving repository prevented the dumb http transport from fetching a good copy of it from the other side. * jk/dumb-http-idx-fetch-fix: dumb-http: do not pass NULL path to parse_pack_index
2015-02-17Merge branch 'jc/apply-ws-fix-expands'Libravatar Junio C Hamano1-0/+121
"git apply --whitespace=fix" used to under-allocate the memory when the fix resulted in a longer text than the original patch. * jc/apply-ws-fix-expands: apply: count the size of postimage correctly apply: make update_pre_post_images() sanity check the given postlen apply.c: typofix
2015-02-17Merge branch 'ks/rebase-i-abbrev'Libravatar Junio C Hamano1-0/+7
The insn sheet "git rebase -i" creates did not fully honor core.abbrev settings. * ks/rebase-i-abbrev: rebase -i: use full object name internally throughout the script
2015-02-17Merge branch 'mh/deref-symref-over-helper-transport'Libravatar Junio C Hamano1-0/+24
"git fetch" over a remote-helper that cannot respond to "list" command could not fetch from a symbolic reference e.g. HEAD. * mh/deref-symref-over-helper-transport: transport-helper: do not request symbolic refs to remote helpers
2015-02-16git-send-email.perl: support no- prefix with older GetOptionsLibravatar Kyle J. McKay1-5/+5
Only Perl version 5.8.0 or later is required, but that comes with an older Getopt::Long (2.32) that does not support the 'no-' prefix. Support for that was added in Getopt::Long version 2.33. Since the help only mentions the 'no-' prefix and not the 'no' prefix, add explicit support for the 'no-' prefix to support older GetOptions versions. Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-15test-lib.sh: set prerequisite SANITY by testing what we really needLibravatar Torsten Bögershausen1-3/+22
What we wanted out of the SANITY precondition is that the filesystem behaves sensibly with permission bits settings. - You should not be able to remove a file in a read-only directory, - You should not be able to tell if a file in a directory exists if the directory lacks read or execute permission bits. We used to cheat by approximating that condition with "is the / writable?" test and/or "are we running as root?" test. Neither test is sufficient or appropriate in environments like Cygwin. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-11Merge branch 'jc/push-to-checkout'Libravatar Junio C Hamano1-0/+63
Extending the js/push-to-deploy topic, the behaviour of "git push" when updating the working tree and the index with an update to the branch that is checked out can be tweaked by push-to-checkout hook. * jc/push-to-checkout: receive-pack: support push-to-checkout hook receive-pack: refactor updateInstead codepath
2015-02-11Merge branch 'sb/atomic-push'Libravatar Junio C Hamano1-0/+194
"git push" has been taught a "--atomic" option that makes push to update more than one ref an "all-or-none" affair. * sb/atomic-push: Document receive.advertiseatomic t5543-atomic-push.sh: add basic tests for atomic pushes push.c: add an --atomic argument send-pack.c: add --atomic command line argument send-pack: rename ref_update_to_be_sent to check_to_send_update receive-pack.c: negotiate atomic push support receive-pack.c: add execute_commands_atomic function receive-pack.c: move transaction handling in a central place receive-pack.c: move iterating over all commands outside execute_commands receive-pack.c: die instead of error in case of possible future bug receive-pack.c: shorten the execute_commands loop over all commands
2015-02-11Merge branch 'cj/log-invert-grep'Libravatar Junio C Hamano1-0/+15
"git log --invert-grep --grep=WIP" will show only commits that do not have the string "WIP" in their messages. * cj/log-invert-grep: log: teach --invert-grep option
2015-02-11Merge branch 'dk/format-patch-ignore-diff-submodule'Libravatar Junio C Hamano1-0/+72
Setting diff.submodule to 'log' made "git format-patch" produce broken patches. * dk/format-patch-ignore-diff-submodule: format-patch: ignore diff.submodule setting t4255: test am submodule with diff.submodule
2015-02-11Merge branch 'ld/p4-exclude-in-sync'Libravatar Junio C Hamano1-0/+71
Like the "clone" subcommand, allow excluding subdirectories in the "sync" subcommand. * ld/p4-exclude-in-sync: git-p4: support excluding paths on sync
2015-02-11git-p4: support excluding paths on syncLibravatar Luke Diamand1-0/+71
The clone subcommand has long had support for excluding subdirectories, but sync has not. This is a nuisance, since as soon as you do a sync, any changed files that were initially excluded start showing up. Move the "exclude" command-line option into the parent class; the actual behavior was already present there so it simply had to be exposed. Signed-off-by: Luke Diamand <luke@diamand.org> Reviewed-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-11Merge branch 'ak/typofixes'Libravatar Junio C Hamano1-1/+1
* ak/typofixes: t/lib-terminal.sh: fix typo pack-bitmap: fix typo
2015-02-11merge-file: correctly open files when in a subdirLibravatar Aleksander Boruch-Gruszecki1-1/+2
run_setup_gently() is called before merge-file. This may result in changing current working directory, which wasn't taken into account when opening a file for writing. Fix by prepending the passed prefix. Previous var is left so that error messages keep referring to the file from the user's working directory perspective. Signed-off-by: Aleksander Boruch-Gruszecki <aleksander.boruchgruszecki@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-10apply: do not touch a file beyond a symbolic linkLibravatar Junio C Hamano2-4/+91
Because Git tracks symbolic links as symbolic links, a path that has a symbolic link in its leading part (e.g. path/to/dir/file, where path/to/dir is a symbolic link to somewhere else, be it inside or outside the working tree) can never appear in a patch that validly applies, unless the same patch first removes the symbolic link to allow a directory to be created there. Detect and reject such a patch. Things to note: - Unfortunately, we cannot reuse the has_symlink_leading_path() from dir.c, as that is only about the working tree, but "git apply" can be told to apply the patch only to the index or to both the index and to the working tree. - We cannot directly use has_symlink_leading_path() even when we are applying only to the working tree, as an early patch of a valid input may remove a symbolic link path/to/dir and then a later patch of the input may create a path path/to/dir/file, but "git apply" first checks the input without touching either the index or the working tree. The leading symbolic link check must be done on the interim result we compute in-core (i.e. after the first patch, there is no path/to/dir symbolic link and it is perfectly valid to create path/to/dir/file). Similarly, when an input creates a symbolic link path/to/dir and then creates a file path/to/dir/file, we need to flag it as an error without actually creating path/to/dir symbolic link in the filesystem. Instead, for any patch in the input that leaves a path (i.e. a non deletion) in the result, we check all leading paths against the resulting tree that the patch would create by inspecting all the patches in the input and then the target of patch application (either the index or the working tree). This way, we catch a mischief or a mistake to add a symbolic link path/to/dir and a file path/to/dir/file at the same time, while allowing a valid patch that removes a symbolic link path/to/dir and then adds a file path/to/dir/file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-10apply: do not read from beyond a symbolic linkLibravatar Junio C Hamano1-0/+19
We should reject a patch, whether it renames/copies dir/file to elsewhere with or without modificiation, or updates dir/file in place, if "dir/" part is actually a symbolic link to elsewhere, by making sure that the code to read the preimage does not read from a path that is beyond a symbolic link. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-10apply: reject input that touches outside the working areaLibravatar Junio C Hamano1-0/+141
By default, a patch that affects outside the working area (either a Git controlled working tree, or the current working directory when "git apply" is used as a replacement of GNU patch) is rejected as a mistake (or a mischief). Git itself does not create such a patch, unless the user bends over backwards and specifies a non-standard prefix to "git diff" and friends. When `git apply` is used as a "better GNU patch", the user can pass the `--unsafe-paths` option to override this safety check. This option has no effect when `--index` or `--cached` is in use. The new test was stolen from Jeff King with slight enhancements. Note that a few new tests for touching outside the working area by following a symbolic link are still expected to fail at this step, but will be fixed in later steps. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-09sha1_file: fix iterating loose alternate objectsLibravatar Jonathon Mah1-0/+8
The string in 'base' contains a path suffix to a specific object; when its value is used, the suffix must either be filled (as in stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared (as in prepare_packed_git) to avoid junk at the end. 660c889e (sha1_file: add for_each iterators for loose and packed objects, 2014-10-15) introduced loose_from_alt_odb(), but this did neither and treated 'base' as a complete path to the "base" object directory, instead of a pointer to the "base" of the full path string. The trailing path after 'base' is still initialized to NUL, hiding the bug in some common cases. Additionally the descendent for_each_file_in_obj_subdir() function swallows ENOENT, so an error only shows if the alternate's path was last filled with a valid object (where statting /path/to/existing/00/0bjectfile/00 fails). Signed-off-by: Jonathon Mah <me@JonathonMah.com> Helped-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-05config: do not ungetc EOFLibravatar Jeff King1-0/+9
When we are parsing a config value, if we see a carriage return, we fgetc the next character to see if it is a line feed (in which case we silently drop the CR). If it isn't, we then ungetc the character, and take the literal CR. But we never check whether we in fact got a character at all. If the config file ends in CR, we will get EOF here, and try to ungetc EOF. This works OK for a real stdio stream. The ungetc returns an error, and the next fgetc will then return EOF again. However, our custom buffer-based stream is not so fortunate. It happily rewinds the position of the stream by one character, ignoring the fact that we fed it EOF. The next fgetc call returns the final CR again, over and over, and we end up in an infinite loop. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-02git-submodule.sh: fix '/././' path normalizationLibravatar Patrick Steinhardt1-0/+17
When we add a new submodule the path of the submodule is being normalized. We fail to normalize multiple adjacent '/./', though. Thus 'path/to/././submodule' will become 'path/to/./submodule' where it should be 'path/to/submodule' instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29t/lib-gpg: sanity-check that we can actually signLibravatar Jeff King1-0/+2
Some older versions of gpg (reportedly v1.2.6 from RHEL4) cannot import the keyrings found in our test suite, and thus cannot even make a signature. The previous change works it around, but we cannot anticipate breakages update to GPG would cause in the future. Do a test-sign before declaring the GPG prerequisite fulfilled to future-proof our tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29t/lib-gpg: include separate public keys in keyring.gpgLibravatar Jeff King2-0/+56
Since 1e3eefb (tests: replace binary GPG keyrings with ASCII-armored keys, 2014-12-12), we import our test GPG keys from a single file. Each keypair in the import stream contains both the secret and public keys. However, older versions of gpg reportedly fail to import the public half of the key. We can solve this by including duplicates of the public keys separately. The duplicates are ignored by modern gpg, and this makes older versions work. Reported by Tom G. Christensen <tgc@statsbiblioteket.dk> on gpg 1.2.6 (from RHEL4). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-28t4122: use test_write_lines from test-lib-functionsLibravatar Junio C Hamano1-9/+2
Instead of using a custom lecho function, just use what the test framework already gives us. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-28http: add Accept-Language header if possibleLibravatar Yi EungJun1-0/+42
Add an Accept-Language header which indicates the user's preferred languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG. Examples: LANGUAGE= -> "" LANGUAGE=ko:en -> "Accept-Language: ko, en;q=0.9, *;q=0.1" LANGUAGE=ko LANG=en_US.UTF-8 -> "Accept-Language: ko, *;q=0.1" LANGUAGE= LANG=en_US.UTF-8 -> "Accept-Language: en-US, *;q=0.1" This gives git servers a chance to display remote error messages in the user's preferred language. Limit the number of languages to 1,000 because q-value must not be smaller than 0.001, and limit the length of Accept-Language header to 4,000 bytes for some HTTP servers which cannot accept such long header. Signed-off-by: Yi EungJun <eungjun.yi@navercorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-27dumb-http: do not pass NULL path to parse_pack_indexLibravatar Jeff King1-0/+18
Once upon a time, dumb http always fetched .idx files directly into their final location, and then checked their validity with parse_pack_index. This was refactored in commit 750ef42 (http-fetch: Use temporary files for pack-*.idx until verified, 2010-04-19), which uses the following logic: 1. If we have the idx already in place, see if it's valid (using parse_pack_index). If so, use it. 2. Otherwise, fetch the .idx to a tempfile, check that, and if so move it into place. 3. Either way, fetch the pack itself if necessary. However, it got step 1 wrong. We pass a NULL path parameter to parse_pack_index, so an existing .idx file always looks broken. Worse, we do not treat this broken .idx as an opportunity to re-fetch, but instead return an error, ignoring the pack entirely. This can lead to a dumb-http fetch failing to retrieve the necessary objects. This doesn't come up much in practice, because it must be a packfile that we found out about (and whose .idx we stored) during an earlier dumb-http fetch, but whose packfile we _didn't_ fetch. I.e., we did a partial clone of a repository, didn't need some packfiles, and now a followup fetch needs them. Discovery and tests by Charles Bailey <charles@hashpling.org>. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-22Merge branch 'js/t1050'Libravatar Junio C Hamano1-6/+6
* js/t1050: t1050-large: generate large files without dd
2015-01-22Merge branch 'jh/empty-notes'Libravatar Junio C Hamano1-1/+1
* jh/empty-notes: Fix unclosed here document in t3301.sh
2015-01-22apply: make update_pre_post_images() sanity check the given postlenLibravatar Junio C Hamano1-0/+121
"git apply --whitespace=fix" used to be able to assume that fixing errors will always reduce the size by e.g. stripping whitespaces at the end of lines or collapsing runs of spaces into tabs at the beginning of lines. An update to accomodate fixes that lengthens the result by e.g. expanding leading tabs into spaces were made long time ago but the logic miscounted the necessary space after such whitespace fixes, leading to either under-allocation or over-usage of already allocated space. Illustrate this with a runtime sanity-check to protect us from future breakage. The test was stolen from Kyle McKay who helped to identify the problem. Helped-by: "Kyle J. McKay" <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-22Fix unclosed here document in t3301.shLibravatar Kacper Kornet1-1/+1
Commit 908a3203632a02568df230c0fccf9a2cd8da24e6 introduced indentation to here documents in t3301.sh. However in one place <<-EOF was missing -, which broke this test when run with mksh-50d. This commit fixes it. Signed-off-by: Kacper Kornet <draenog@pld-linux.org> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-22rebase -i: use full object name internally throughout the scriptLibravatar Kirill A. Shutemov1-0/+7
In earlier days, the abbreviated commit object name shown to the end users were generated with hardcoded --abbrev=7; 56895038 (rebase -i: respect core.abbrev, 2013-09-28) tried to make it honor the user specified core.abbrev, but it missed the very initial invocation of the editor. These days, we try to use the full 40-hex object names internally to avoid ambiguity that can arise after rebase starts running. Newly created objects during the rebase may share the same prefix with existing commits listed in the insn sheet. These object names are shortened just before invoking the sequence editor to present the insn sheet to the end user, and then expanded back to full object names when the editor returns. But the code still used the shortened names when preparing the insn sheet for the very first time, resulting "7 hexdigits or more" output to the user. Change the code to use full 40-hex commit object names from the very beginning to make things more uniform. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-21transport-helper: do not request symbolic refs to remote helpersLibravatar Mike Hommey1-0/+24
A typical remote helper will return a `list` of refs containing a symbolic ref HEAD, pointing to, e.g. refs/heads/master. In the case of a clone, all the refs are being requested through `fetch` or `import`, including the symbolic ref. While this works properly, in some cases of a fetch, like `git fetch url` or `git fetch origin HEAD`, or any fetch command involving a symbolic ref without also fetching the corresponding ref it points to, the fetch command fails with: fatal: bad object 0000000000000000000000000000000000000000 error: <remote> did not send all necessary objects (in the case the remote helper returned '?' values to the `list` command). This is because there is only one ref given to fetch(), and it's not further resolved to something at the end of fetch_with_import(). While this can be somehow handled in the remote helper itself, by adding a refspec for the symbolic ref, and storing an explicit ref in a private namespace, and then handling the `import` for that symbolic ref specifically, very few existing remote helpers are actually doing that. So, instead of requesting the exact list of wanted refs to remote helpers, treat symbolic refs differently and request the ref they point to instead. Then, resolve the symbolic refs values based on the pointed ref. This assumes there is no more than one level of indirection (a symbolic ref doesn't point to another symbolic ref). Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-21t/lib-terminal.sh: fix typoLibravatar Alexander Kuleshov1-1/+1
Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-20Merge branch 'jk/colors'Libravatar Junio C Hamano1-0/+4
* jk/colors: parse_color: fix return value for numeric color values 0-8
2015-01-20parse_color: fix return value for numeric color values 0-8Libravatar Jeff King1-0/+4
When commit 695d95d refactored the color parsing, it missed a "return 0" when parsing literal numbers 0-8 (which represent basic ANSI colors), leading us to report these colors as an error. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>