Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.kernel.org/pub/scm/git/git.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-01-26daemon: fix length computation in newline strippingJeff King
When git-daemon gets a pktline request, we strip off any trailing newline, replacing it with a NUL. Clients prior to 5ad312bede (in git v1.4.0) would send: git-upload-pack repo.git\n and we need to strip it off to understand their request. After 5ad312bede, we send the host attribute but no newline, like: git-upload-pack repo.git\0host=example.com\0 Both of these are parsed correctly by git-daemon. But if some client were to combine the two: git-upload-pack repo.git\n\0host=example.com\0 we don't parse it correctly. The problem is that we use the "len" variable to record the position of the NUL separator, but then decrement it when we strip the newline. So we start with: git-upload-pack repo.git\n\0host=example.com\0 ^-- len and end up with: git-upload-pack repo.git\0\0host=example.com\0 ^-- len This is arguably correct, since "len" tells us the length of the initial string, but we don't actually use it for that. What we do use it for is finding the offset of the extended attributes; they used to be at len+1, but are now at len+2. We can solve that by just leaving "len" where it is. We don't have to care about the length of the shortened string, since we just treat it like a C string. No version of Git ever produced such a string, but it seems like the daemon code meant to handle this case (and it seems like a reasonable thing for somebody to do in a 3rd-party implementation). Reported-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-26t/lib-git-daemon: add network-protocol helpersJeff King
All of our git-protocol tests rely on invoking the client and having it make a request of a server. That gives a nice real-world test of how the two behave together, but it doesn't leave any room for testing how a server might react to _other_ clients. Let's add a few test helper functions which can be used to manually conduct a git-protocol conversation with a remote git-daemon: 1. To connect to a remote git-daemon, we need something like "netcat". But not everybody will have netcat. And even if they do, the behavior with respect to half-duplex shutdowns is not portable (openbsd netcat has "-N", with others you must rely on "-q 1", which is racy). Here we provide a "fake_nc" that is capable of doing a client-side netcat, with sane half-duplex semantics. It relies on perl's IO::Socket::INET. That's been in the base distribution since 5.6.0, so it's probably available everywhere. But just to be on the safe side, we'll add a prereq. 2. To help tests speak and read pktline, this patch adds packetize() and depacketize() functions. I've put fake_nc() into lib-git-daemon.sh, since that's really the only server where we'd need to use a network socket. Whereas the pktline helpers may be of more general use, so I've added them to test-lib-functions.sh. Programs like upload-pack speak pktline, but can talk directly over stdio without a network socket. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-26daemon: handle NULs in extended attribute stringJeff King
If we receive a request with extended attributes after the NUL, we try to write those attributes to the log. We do so with a "%s" format specifier, which will only show characters up to the first NUL. That's enough for printing a "host=" specifier. But since dfe422d04d (daemon: recognize hidden request arguments, 2017-10-16) we may have another NUL, followed by protocol parameters, and those are not logged at all. Let's cut out the attempt to show the whole string, and instead log when we parse individual attributes. We could leave the "extended attributes (%d bytes) exist" part of the log, which in theory could alert us to attributes that fail to parse. But anything we don't parse as a "host=" parameter gets blindly added to the "protocol" attribute, so we'd see it in that part of the log. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-26daemon: fix off-by-one in logging extended attributesJeff King
If receive a request like: git-upload-pack /foo.git\0host=localhost we mark the offset of the NUL byte as "len", and then log the bytes after the NUL with a "%.*s" placeholder, using "pktlen - len" as the length, and "line + len + 1" as the start of the string. This is off-by-one, since the start of the string skips past the separating NUL byte, but the adjusted length includes it. Fortunately this doesn't actually read past the end of the buffer, since "%.*s" will stop when it hits a NUL. And regardless of what is in the buffer, packet_read() will always add an extra NUL terminator for safety. As an aside, the git.git client sends an extra NUL after a "host" field, too, so we'd generally hit that one first, not the one added by packet_read(). You can see this in the test output which reports 15 bytes, even though the string has only 14 bytes of visible data. But the point is that even a client sending unusual data could not get us to read past the end of the buffer, so this is purely a cosmetic fix. Reported-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-26t/lib-git-daemon: record daemon logJeff King
When we start git-daemon for our tests, we send its stderr log stream to a named pipe. We synchronously read the first line to make sure that the daemon started, and then dump the rest to descriptor 4. This is handy for debugging test output with "--verbose", but the tests themselves can't access the log data. Let's dump the log into a file, as well, so that future tests can check the log. There are a few subtleties worth calling out here: - we'll continue to send output to descriptor 4 for viewing/debugging, which would imply swapping out "cat" for "tee". But we want to ensure that there's no buffering, and "tee" doesn't have a standard way to ask for that. So we'll use a shell loop around "read" and "printf" instead. That ensures that after a request has been served, the matching log entries will have made it to the file. - the existing first-line shell loop used read/echo. We'll switch to consistently using "read -r" and "printf" to relay data as faithfully as possible. - we open the logfile for append, rather than just output. That makes it OK for tests to truncate the logfile without restarting the daemon (the OS will atomically seek to the end of the file when outputting each line). That allows tests to look at the log without worrying about pollution from earlier tests. Helped-by: Lucas Werkmeister <mail@lucaswerkmeister.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25t5570: use ls-remote instead of clone for interp testsJeff King
We don't actually care about the clone operation here; we just want to know if we were able to actually contact the remote repository. Using ls-remote does that more efficiently, and without us having to worry about managing the tmp.git directory. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-24mailinfo: avoid segfault when can't open filesJuan F. Codagnone
If <msg> or <patch> files can't be opened, then mailinfo() returns an error before it even initializes mi->p_hdr_data or mi->s_hdr_data. When cmd_mailinfo() then calls clear_mailinfo(), we dereference the NULL pointers trying to free their contents. Signed-off-by: Juan F. Codagnone <jcodagnone@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-24read-cache: don't write index twice if we can't write shared indexNguyễn Thái Ngọc Duy
In a0a967568e ("update-index --split-index: do not split if $GIT_DIR is read only", 2014-06-13), we tried to make sure we can still write an index, even if the shared index can not be written. We did so by just calling 'do_write_locked_index()' just before 'write_shared_index()'. 'do_write_locked_index()' always at least closes the tempfile nowadays, and used to close or commit the lockfile if COMMIT_LOCK or CLOSE_LOCK were given at the time this feature was introduced. COMMIT_LOCK or CLOSE_LOCK is passed in by most callers of 'write_locked_index()'. After calling 'write_shared_index()', we call 'write_split_index()', which calls 'do_write_locked_index()' again, which then tries to use the closed lockfile again, but in fact fails to do so as it's already closed. This eventually leads to a segfault. Make sure to write the main index only once. [nd: most of the commit message and investigation done by Thomas, I only tweaked the solution a bit] Helped-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-23fsck: fix leak when traversing treesEric Wong
While fsck_walk/fsck_walk_tree/parse_tree populates "struct tree" idempotently, it is still up to the fsck_walk caller to call free_tree_buffer. Fixes: ad2db4030e42890e ("fsck: remove redundant parse_tree() invocation") Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-22Git 2.16.1v2.16.1Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-22Merge branch 'bc/hash-algo' into maintJunio C Hamano
* bc/hash-algo: t5601-clone: test case-conflicting files on case-insensitive filesystem repository: pre-initialize hash algo pointer
2018-01-22t5601-clone: test case-conflicting files on case-insensitive filesystemEric Sunshine
A recently introduced regression caused a segfault at clone time on case-insensitive filesystems when filenames differing only in case are present. This bug has already been fixed (repository: pre-initialize hash algo pointer, 2018-01-18), but it's not the first time similar problems have arisen. Therefore, introduce a test to catch this case and protect against future regressions. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-20repository: pre-initialize hash algo pointerbrian m. carlson
There are various git subcommands (among them, clone) which don't set up the repository (that is, they lack RUN_SETUP or RUN_SETUP_GENTLY) but end up needing to have information about the hash algorithm in use. Because the hash algorithm is part of struct repository and it's only initialized in repository setup, we can end up dereferencing a NULL pointer in some cases if we call one of these subcommands and look up the empty blob or empty tree values. A "git clone" of a project that has two paths that differ only in case suffers from this if it is run on a case insensitive platform. When the command attempts to check out one of these two paths after checking out the other one, the checkout codepath needs to see if the version that is already on the filesystem (which should not happen if the FS were case sensitive) is dirty, and it needs to exercise the hashing code at that point. In the future, we can add a command line option for this or read it from the configuration, but until we're ready to expose that functionality to the user, simply initialize the repository structure to use the current hash algorithm, SHA-1. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-20files_initial_transaction_commit(): only unlock if lockedMathias Rav
Running git clone --single-branch --mirror -b TAGNAME previously triggered the following error message: fatal: multiple updates for ref 'refs/tags/TAGNAME' not allowed. This error condition is handled in files_initial_transaction_commit(). 42c7f7ff9 ("commit_packed_refs(): remove call to `packed_refs_unlock()`", 2017-06-23) introduced incorrect unlocking in the error path of this function, which changes the error message to fatal: BUG: packed_refs_unlock() called when not locked Move the call to packed_refs_unlock() above the "cleanup:" label since the unlocking should only be done in the last error path. Signed-off-by: Mathias Rav <m@git.strova.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-20http: support omitting data from tracesJonathan Tan
GIT_TRACE_CURL provides a way to debug what is being sent and received over HTTP, with automatic redaction of sensitive information. But it also logs data transmissions, which significantly increases the log file size, sometimes unnecessarily. Add an option "GIT_TRACE_CURL_NO_DATA" to allow the user to omit such data transmissions. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-20http: support cookie redaction when tracingJonathan Tan
When using GIT_TRACE_CURL, Git already redacts the "Authorization:" and "Proxy-Authorization:" HTTP headers. Extend this redaction to a user-specified list of cookies, specified through the "GIT_REDACT_COOKIES" environment variable. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-19travis: run tests with GIT_TEST_SPLIT_INDEXThomas Gummerer
Split index mode only has a few dedicated tests, but as the index is involved in nearly every git operation, this doesn't quite cover all the ways repositories with split index can break. To use split index mode throughout the test suite a GIT_TEST_SPLIT_INDEX environment variable can be set, which makes git split the index at random and thus excercises the functionality much more thoroughly. As this is not turned on by default, it is not executed nearly as often as the test suite is run, so occationally breakages slip through. Try to counteract that by running the test suite with GIT_TEST_SPLIT_INDEX mode turned on on travis. To avoid using too many cycles on travis only run split index mode in the linux-gcc target only. The Linux build was chosen over the Mac OS builds because it tends to be much faster to complete. The linux gcc build was chosen over the linux clang build because the linux clang build is the fastest build, so it can serve as an early indicator if something is broken and we want to avoid spending the extra cycles of running the test suite twice for that. Helped-by: Lars Schneider <larsxschneider@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-19split-index: don't write cache tree with null oid entriesThomas Gummerer
In a96d3cc3f6 ("cache-tree: reject entries with null sha1", 2017-04-21) we made sure that broken cache entries do not get propagated to new trees. Part of that was making sure not to re-use an existing cache tree that includes a null oid. It did so by dropping the cache tree in 'do_write_index()' if one of the entries contains a null oid. In split index mode however, there are two invocations to 'do_write_index()', one for the shared index and one for the split index. The cache tree is only written once, to the split index. As we only loop through the elements that are effectively being written by the current invocation, that may not include the entry with a null oid in the split index (when it is already written to the shared index), where we write the cache tree. Therefore in split index mode we may still end up writing the cache tree, even though there is an entry with a null oid in the index. Fix this by checking for null oids in prepare_to_write_split_index, where we loop the entries of the shared index as well as the entries for the split index. This fixes t7009 with GIT_TEST_SPLIT_INDEX. Also add a new test that's more specifically showing the problem. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-19read-cache: fix reading the shared index for other reposThomas Gummerer
read_index_from() takes a path argument for the location of the index file. For reading the shared index in split index mode however it just ignores that path argument, and reads it from the gitdir of the current repository. This works as long as an index in the_repository is read. Once that changes, such as when we read the index of a submodule, or of a different working tree than the current one, the gitdir of the_repository will no longer contain the appropriate shared index, and git will fail to read it. For example t3007-ls-files-recurse-submodules.sh was broken with GIT_TEST_SPLIT_INDEX set in 188dce131f ("ls-files: use repository object", 2017-06-22), and t7814-grep-recurse-submodules.sh was also broken in a similar manner, probably by introducing struct repository there, although I didn't track down the exact commit for that. be489d02d2 ("revision.c: --indexed-objects add objects from all worktrees", 2017-08-23) breaks with split index mode in a similar manner, not erroring out when it can't read the index, but instead carrying on with pruning, without taking the index of the worktree into account. Fix this by passing an additional gitdir parameter to read_index_from, to indicate where it should look for and read the shared index from. read_cache_from() defaults to using the gitdir of the_repository. As it is mostly a convenience macro, having to pass get_git_dir() for every call seems overkill, and if necessary users can have more control by using read_index_from(). Helped-by: Brandon Williams <bmwill@google.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-18Git 2.16v2.16.0Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-17worktree: say that "add" takes an arbitrary commit in short-helpJunio C Hamano
c4738aed ("worktree: add can be created from any commit-ish", 2017-11-26) taught "git worktree add" to start a new worktree with an arbitrary commit-ish checked out, not limited to a tip of a branch. "git worktree --help" was updated to describe this, but we forgot to update "git worktree -h". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-17Merge tag 'l10n-2.16.0-rnd2' of git://github.com/git-l10n/git-poJunio C Hamano
l10n for Git 2.16.0 round 2 * tag 'l10n-2.16.0-rnd2' of git://github.com/git-l10n/git-po: (24 commits) l10n: de.po: translate 72 new messages l10n: de.po: improve messages when a branch starts to track another ref l10n: bg.po: Updated Bulgarian translation (3288t) l10n: TEAMS: add zh_CN team members l10n: zh_CN: for git v2.16.0 l10n round 2 l10n: sv.po: Update Swedish translation (3288t0f0u) l10n: ru.po: update Russian translation l10n: TEAMS: Add ko team members l10n: ko.po: Update Korean translation l10n: fr.po 2.16 round 2 l10n: es.po: Spanish translation 2.16.0 round 2 l10n: vi.po(3288t): Updated Vietnamese translation for v2.16.0 round 2 l10n: git.pot: v2.16.0 round 2 (8 new, 4 removed) l10n: es.po: Update Spanish Translation v2.16.0 l10n: fr.po v2.16.0 round 1 l10n: bg.po: Updated Bulgarian translation (3284t) l10n: sv.po: Update Swedish translation (3284t0f0u) l10n: fr.po: "worktree list" mistranslated as prune l10n: git.pot: v2.16.0 round 1 (64 new, 25 removed) l10n: fixes to German translation ...
2018-01-17diff.c: flush stdout before printing rename warningsNguyễn Thái Ngọc Duy
The diff output is buffered in a FILE object and could still be partially buffered when we print these warnings (directly to fd 2). The output is messed up like this worktree.c | 138 +- worktree.h warning: inexact rename detection was skipped due to too many files. | 12 +- wrapper.c | 83 +- It gets worse if the warning is printed after color codes for the graph part are already printed. You'll get a warning in green or red. Flush stdout first, so we can get something like this instead: xdiff/xutils.c | 42 +- xdiff/xutils.h | 4 +- 1033 files changed, 150824 insertions(+), 69395 deletions(-) warning: inexact rename detection was skipped due to too many files. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-17hashmap.h: remove unused variableRandall S. Becker
In 'hashmap_enable_item_counting()', item is assigned but never used. This causes a warning on HP NonStop. As the variable is never used, fix this by just removing it. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Helped-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-17describe: use strbuf_add_unique_abbrev() for adding short hashesRené Scharfe
Call strbuf_add_unique_abbrev() to add an abbreviated hash to a strbuf instead of taking a detour through find_unique_abbrev() and its static buffer. This is shorter and a bit more efficient. Patch generated by Coccinelle (and contrib/coccinelle/strbuf.cocci). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-17read-cache.c: move tempfile creation/cleanup out of write_shared_indexNguyễn Thái Ngọc Duy
For one thing, we have more consistent cleanup procedure now and always keep errno intact. The real purpose is the ability to break out of write_locked_index() early when mks_tempfile() fails in the next patch. It's more awkward to do it if this mks_tempfile() is still inside write_shared_index(). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-17read-cache.c: change type of "temp" in write_shared_index()Nguyễn Thái Ngọc Duy
This local variable 'temp' will be passed in from the caller in the next patch. To reduce patch noise, let's change its type now while it's still a local variable and get all the trival conversion out of the next patch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-16add--interactive: ignore submodule changes except HEADNguyễn Thái Ngọc Duy
For 'add -i' and 'add -p', the only action we can take on a dirty submodule entry is update the index with a new value from its HEAD. The content changes inside (from its own index, untracked files...) do not matter, at least until 'git add -i' learns about launching a new interactive add session inside a submodule. Ignore all other submodules changes except HEAD. This reduces the number of entries the user has to check through in 'git add -i', and the number of 'no' they have to answer to 'git add -p' when dirty submodules are present. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-16Doc/git-submodule: improve readability and grammar of a sentenceKaartic Sivaraam
While at it, correctly quote important words. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-16Doc/gitsubmodules: make some changes to improve readability and syntaxKaartic Sivaraam
* Only mention porcelain commands in examples * Split a sentence for better readability * Add missing apostrophes * Clearly specify the advantages of using submodules * Avoid abbreviations * Use "Git" consistently * Improve readability of certain lines * Clarify when a submodule is considered active Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-15l10n: de.po: translate 72 new messagesRalf Thielow
Translate 72 new messages came from git.pot update in 18a907225 (l10n: git.pot: v2.16.0 round 1 (64 new, 25 removed)) and 005c62fe4 (l10n: git.pot: v2.16.0 round 2 (8 new, 4 removed)). Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Matthias Rüster <matthias.ruester@gmail.com>
2018-01-15l10n: de.po: improve messages when a branch starts to track another refRalf Thielow
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2018-01-12RelNotes: minor typofixSZEDER Gábor
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-12t9001: use existing helper in send-email testChristian Ludwig
Use the wrapper function around the sed statement like everywhere else in the test. Unfortunately the wrapper function is defined pretty late. Move the wrapper to the top of the test file, so future users have it available right away. Signed-off-by: Christian Ludwig <chrissicool@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-12Git 2.16-rc2v2.16.0-rc2Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-12Merge branch 'jh/object-filtering'Junio C Hamano
Hotfix for a topic already in 'master'. * jh/object-filtering: oidset: don't return value from oidset_init
2018-01-12Merge branch 'tg/worktree-create-tracking'Junio C Hamano
Doc hotfix. * tg/worktree-create-tracking: Documentation/git-worktree.txt: add missing `
2018-01-12Merge branch 'js/test-with-ws-in-path'Junio C Hamano
Hot fix to a test. * js/test-with-ws-in-path: t3900: add some more quotes
2018-01-12l10n: bg.po: Updated Bulgarian translation (3288t)Alexander Shopov
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2018-01-11Documentation/git-worktree.txt: add missing `Ralf Thielow
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-11cat-file doc: document that -e will return some outputÆvar Arnfjörð Bjarmason
The -e option added in 7950571ad7 ("A few more options for git-cat-file", 2005-12-03) has always errored out with message on stderr saying that the provided object is malformed, like this: $ git cat-file -e malformed; echo $? fatal: Not a valid object name malformed 128 A reader of this documentation may be misled into thinking that if ! git cat-file -e "$object" [...] as opposed to: if ! git cat-file -e "$object" 2>/dev/null [...] is sufficient to implement a truly silent test that checks whether some arbitrary $object string was both valid, and pointed to an object that exists. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-11t3900: add some more quotesBeat Bolli
In 89a70b80 ("t0302 & t3900: add forgotten quotes", 2018-01-03), quotes were added to protect against spaces in $HOME. In the test_when_finished command, two files are deleted which must be quoted individually. [jc: with \$HOME in the test_when_finished command quoted, as pointed out by j6t]. Signed-off-by: Beat Bolli <dev+git@drbeat.li> Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-11RelNotes update before -rc2Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-11Merge branch 'js/perl-path-workaround-in-tests'Junio C Hamano
* js/perl-path-workaround-in-tests: mingw: handle GITPERLLIB in t0021 in a Windows-compatible way
2018-01-11Merge branch 'ew/empty-merge-with-dirty-index'Junio C Hamano
"git merge -s recursive" did not correctly abort when the index is dirty, if the merged tree happened to be the same as the current HEAD, which has been fixed. * ew/empty-merge-with-dirty-index: merge-recursive: do not look at the index during recursive merge
2018-01-11Merge branch 'ma/bisect-leakfix'Junio C Hamano
A hotfix for a recent update that broke 'git bisect'. * ma/bisect-leakfix: bisect: fix a regression causing a segfault
2018-01-11Merge branch 'js/fix-merge-arg-quoting-in-rebase-p'Junio C Hamano
"git rebase -p -X<option>" did not propagate the option properly down to underlying merge strategy backend. * js/fix-merge-arg-quoting-in-rebase-p: rebase -p: fix quoting when calling `git merge`
2018-01-11mingw: handle GITPERLLIB in t0021 in a Windows-compatible wayJohannes Schindelin
Git's assumption that all path lists are colon-separated is not only wrong on Windows, it is not even an assumption that is compatible with POSIX. In the interest of time, let's not try to fix this properly but simply work around the obvious breakage on Windows, where the MSYS2 Bash used by Git for Windows to interpret the Git's Unix shell scripts will automagically convert path lists in the environment to semicolon-separated lists of Windows paths (with drive letter and the corresponding colon and all that jazz). In other words, we simply look whether there is a semicolon in GITPERLLIB and split by semicolons if found instead of colons. This is not fool-proof, of course, as the path list could consist of a single path. But that is not the case in Git for Windows' test suite, there are always two paths in GITPERLLIB. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-10l10n: TEAMS: add zh_CN team membersJiang Xin
Add Fangyi Zhou to zh_CN l10n team members. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2018-01-10l10n: zh_CN: for git v2.16.0 l10n round 2Jiang Xin
Translate 72 messages (3288t0f0u) for git v2.16.0-rc1. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: 依云 <lilydjwg@gmail.com> Reviewed-by: Fangyi Zhou <fangyi.zhou@yuriko.moe>