summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-10-03Merge branch 'jk/read-in-full'Libravatar Junio C Hamano10-17/+55
Code clean-up to prevent future mistakes by copying and pasting code that checks the result of read_in_full() function. * jk/read-in-full: worktree: check the result of read_in_full() worktree: use xsize_t to access file size distinguish error versus short read from read_in_full() avoid looking at errno for short read_in_full() returns prefer "!=" when checking read_in_full() result notes-merge: drop dead zero-write code files-backend: prefer "0" for write_in_full() error check
2017-10-03Merge branch 'jk/no-optional-locks'Libravatar Junio C Hamano6-1/+41
Some commands (most notably "git status") makes an opportunistic update when performing a read-only operation to help optimize later operations in the same repository. The new "--no-optional-locks" option can be passed to Git to disable them. * jk/no-optional-locks: git: add --no-optional-locks option
2017-10-03Merge branch 'hn/string-list-doc'Libravatar Junio C Hamano2-239/+162
Doc reorg. * hn/string-list-doc: string-list.h: move documentation from Documentation/api/ into header
2017-10-03Merge branch 'hn/path-ownership-comment'Libravatar Junio C Hamano2-1/+6
Add comment to a few functions that use a short-lived buffer the caller can peek and copy out of. * hn/path-ownership-comment: read_gitfile_gently: clarify return value ownership. real_path: clarify return value ownership
2017-10-03Merge branch 'hn/submodule-comment'Libravatar Junio C Hamano1-0/+4
* hn/submodule-comment: submodule.c: describe submodule_to_gitdir() in a new comment
2017-10-03Merge branch 'sd/branch-copy'Libravatar Junio C Hamano10-48/+478
"git branch" learned "-c/-C" to create a new branch by copying an existing one. * sd/branch-copy: branch: fix "copy" to never touch HEAD branch: add a --copy (-c) option to go with --move (-m) branch: add test for -m renaming multiple config sections config: create a function to format section headers
2017-10-03Merge branch 'bc/rev-parse-parseopt-fix'Libravatar Junio C Hamano6-10/+139
Recent versions of "git rev-parse --parseopt" did not parse the option specification that does not have the optional flags (*=?!) correctly, which has been corrected. * bc/rev-parse-parseopt-fix: parse-options: only insert newline in help text if needed parse-options: write blank line to correct output stream t0040,t1502: Demonstrate parse_options bugs git-rebase: don't ignore unexpected command line arguments rev-parse parseopt: interpret any whitespace as start of help text rev-parse parseopt: do not search help text for flag chars t1502: demonstrate rev-parse --parseopt option mis-parsing
2017-10-03Merge branch 'js/rebase-i-final'Libravatar Junio C Hamano7-360/+647
The final batch to "git rebase -i" updates to move more code from the shell script to C. * js/rebase-i-final: rebase -i: rearrange fixup/squash lines using the rebase--helper t3415: test fixup with wrapped oneline rebase -i: skip unnecessary picks using the rebase--helper rebase -i: check for missing commits in the rebase--helper t3404: relax rebase.missingCommitsCheck tests rebase -i: also expand/collapse the SHA-1s via the rebase--helper rebase -i: do not invent onelines when expanding/collapsing SHA-1s rebase -i: remove useless indentation rebase -i: generate the script via rebase--helper t3415: verify that an empty instructionFormat is handled as before
2017-09-29The eleventh batch for 2.15Libravatar Junio C Hamano1-0/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-29Merge branch 'sb/doc-config-submodule-update'Libravatar Junio C Hamano1-4/+8
* sb/doc-config-submodule-update: Documentation/config: clarify the meaning of submodule.<name>.update
2017-09-29Merge branch 'ma/leakplugs'Libravatar Junio C Hamano17-35/+75
Memory leaks in various codepaths have been plugged. * ma/leakplugs: pack-bitmap[-write]: use `object_array_clear()`, don't leak object_array: add and use `object_array_pop()` object_array: use `object_array_clear()`, not `free()` leak_pending: use `object_array_clear()`, not `free()` commit: fix memory leak in `reduce_heads()` builtin/commit: fix memory leak in `prepare_index()`
2017-09-29Merge branch 'rj/no-sign-compare'Libravatar Junio C Hamano10-24/+25
Many codepaths have been updated to squelch -Wsign-compare warnings. * rj/no-sign-compare: ALLOC_GROW: avoid -Wsign-compare warnings cache.h: hex2chr() - avoid -Wsign-compare warnings commit-slab.h: avoid -Wsign-compare warnings git-compat-util.h: xsize_t() - avoid -Wsign-compare warnings
2017-09-29Merge branch 'sb/merge-commit-msg-hook'Libravatar Junio C Hamano1-5/+4
As "git commit" to conclude a conflicted "git merge" honors the commit-msg hook, "git merge" that records a merge commit that cleanly auto-merges should, but it didn't. * sb/merge-commit-msg-hook (2017-09-22) 1 commit (merged to 'next' on 2017-09-25 at 096e0502a8) + Documentation/githooks: mention merge in commit-msg hook Add documentation for a topic that has recently graduated to the 'master' branch. * sb/merge-commit-msg-hook: Documentation/githooks: mention merge in commit-msg hook
2017-09-29Merge branch 'jt/fast-export-copy-modify-fix'Libravatar Junio C Hamano2-15/+51
"git fast-export" with -M/-C option issued "copy" instruction on a path that is simultaneously modified, which was incorrect. * jt/fast-export-copy-modify-fix: fast-export: do not copy from modified file
2017-09-29Merge branch 'mk/describe-match-with-all'Libravatar Junio C Hamano3-22/+58
"git describe --match <pattern>" has been taught to play well with the "--all" option. * mk/describe-match-with-all: describe: teach --match to handle branches and remotes
2017-09-29Merge branch 'jm/status-ignored-directory-optim'Libravatar Junio C Hamano1-6/+41
"git status --ignored", when noticing that a directory without any tracked path is ignored, still enumerated all the ignored paths in the directory, which is unnecessary. The codepath has been optimized to avoid this overhead. * jm/status-ignored-directory-optim: Improve performance of git status --ignored
2017-09-28The tenth batch for 2.15Libravatar Junio C Hamano1-0/+47
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-28Merge branch 'js/win32-lazyload-dll'Libravatar Junio C Hamano1-0/+57
Add a helper in anticipation for its need in a future topic RSN. * js/win32-lazyload-dll: Win32: simplify loading of DLL functions
2017-09-28Merge branch 'jc/merge-x-theirs-docfix'Libravatar Junio C Hamano1-1/+2
The documentation for '-X<option>' for merges was misleadingly written to suggest that "-s theirs" exists, which is not the case. * jc/merge-x-theirs-docfix: merge-strategies: avoid implying that "-s theirs" exists
2017-09-28Merge branch 'ks/doc-use-camelcase-for-config-name'Libravatar Junio C Hamano2-3/+3
Doc update. * ks/doc-use-camelcase-for-config-name: doc: camelCase the config variables to improve readability
2017-09-28Merge branch 'mk/diff-delta-avoid-large-offset'Libravatar Junio C Hamano1-0/+3
The delta format used in the packfile cannot reference data at offset larger than what can be expressed in 4-byte, but the generator for the data failed to make sure the offset does not overflow. This has been corrected. * mk/diff-delta-avoid-large-offset: diff-delta: do not allow delta offset truncation
2017-09-28Merge branch 'mk/diff-delta-uint-may-be-shorter-than-ulong'Libravatar Junio C Hamano1-11/+13
The machinery to create xdelta used in pack files received the sizes of the data in size_t, but lost the higher bits of them by storing them in "unsigned int" during the computation, which is fixed. * mk/diff-delta-uint-may-be-shorter-than-ulong: diff-delta: fix encoding size that would not fit in "unsigned int"
2017-09-28Merge branch 'rs/resolve-ref-optional-result'Libravatar Junio C Hamano17-46/+29
Code clean-up. * rs/resolve-ref-optional-result: refs: pass NULL to resolve_ref_unsafe() if hash is not needed refs: pass NULL to refs_resolve_ref_unsafe() if hash is not needed refs: make sha1 output parameter of refs_resolve_ref_unsafe() optional
2017-09-28Merge branch 'rs/mailinfo-qp-decode-fix'Libravatar Junio C Hamano1-3/+8
"git mailinfo" was loose in decoding quoted printable and produced garbage when the two letters after the equal sign are not hexadecimal. This has been fixed. * rs/mailinfo-qp-decode-fix: mailinfo: don't decode invalid =XY quoted-printable sequences
2017-09-28Merge branch 'jk/doc-read-tree-table-asciidoctor-fix'Libravatar Junio C Hamano1-0/+2
A docfix. * jk/doc-read-tree-table-asciidoctor-fix: doc: put literal block delimiter around table
2017-09-28Merge branch 'ik/userdiff-html-h-element-fix'Libravatar Junio C Hamano1-1/+1
The built-in pattern to detect the "function header" for HTML did not match <H1>..<H6> elements without any attributes, which has been fixed. * ik/userdiff-html-h-element-fix: userdiff: fix HTML hunk header regexp
2017-09-28Merge branch 'jk/fallthrough'Libravatar Junio C Hamano15-28/+30
Many codepaths have been updated to squelch -Wimplicit-fallthrough warnings from Gcc 7 (which is a good code hygiene). * jk/fallthrough: consistently use "fallthrough" comments in switches curl_trace(): eliminate switch fallthrough test-line-buffer: simplify command parsing
2017-09-28Merge branch 'jk/diff-blob'Libravatar Junio C Hamano2-2/+7
"git cat-file --textconv" started segfaulting recently, which has been corrected. * jk/diff-blob: cat-file: handle NULL object_context.path
2017-09-28Merge branch 'hn/typofix'Libravatar Junio C Hamano1-1/+1
* hn/typofix: submodule.h: typofix
2017-09-28Merge branch 'ic/fix-filter-branch-to-handle-tag-without-tagger'Libravatar Junio C Hamano2-8/+94
"git filter-branch" cannot reproduce a history with a tag without the tagger field, which only ancient versions of Git allowed to be created. This has been corrected. * ic/fix-filter-branch-to-handle-tag-without-tagger: filter-branch: use hash-object instead of mktag filter-branch: stash away ref map in a branch filter-branch: preserve and restore $GIT_AUTHOR_* and $GIT_COMMITTER_* filter-branch: reset $GIT_* before cleaning up
2017-09-28Merge branch 'jk/describe-omit-some-refs'Libravatar Junio C Hamano2-4/+11
"git describe --match" learned to take multiple patterns in v2.13 series, but the feature ignored the patterns after the first one and did not work at all. This has been fixed. * jk/describe-omit-some-refs: describe: fix matching to actually match all patterns
2017-09-27git: add --no-optional-locks optionLibravatar Jeff King6-1/+41
Some tools like IDEs or fancy editors may periodically run commands like "git status" in the background to keep track of the state of the repository. Some of these commands may refresh the index and write out the result in an opportunistic way: if they can get the index lock, then they update the on-disk index with any updates they find. And if not, then their in-core refresh is lost and just has to be recomputed by the next caller. But taking the index lock may conflict with other operations in the repository. Especially ones that the user is doing themselves, which _aren't_ opportunistic. In other words, "git status" knows how to back off when somebody else is holding the lock, but other commands don't know that status would be happy to drop the lock if somebody else wanted it. There are a couple possible solutions: 1. Have some kind of "pseudo-lock" that allows other commands to tell status that they want the lock. This is likely to be complicated and error-prone to implement (and maybe even impossible with just dotlocks to work from, as it requires some inter-process communication). 2. Avoid background runs of commands like "git status" that want to do opportunistic updates, preferring instead plumbing like diff-files, etc. This is awkward for a couple of reasons. One is that "status --porcelain" reports a lot more about the repository state than is available from individual plumbing commands. And two is that we actually _do_ want to see the refreshed index. We just don't want to take a lock or write out the result. Whereas commands like diff-files expect us to refresh the index separately and write it to disk so that they can depend on the result. But that write is exactly what we're trying to avoid. 3. Ask "status" not to lock or write the index. This is easy to implement. The big downside is that any work done in refreshing the index for such a call is lost when the process exits. So a background process may end up re-hashing a changed file multiple times until the user runs a command that does an index refresh themselves. This patch implements the option 3. The idea (and the test) is largely stolen from a Git for Windows patch by Johannes Schindelin, 67e5ce7f63 (status: offer *not* to lock the index and update it, 2016-08-12). The twist here is that instead of making this an option to "git status", it becomes a "git" option and matching environment variable. The reason there is two-fold: 1. An environment variable is carried through to sub-processes. And whether an invocation is a background process or not should apply to the whole process tree. So you could do "git --no-optional-locks foo", and if "foo" is a script or alias that calls "status", you'll still get the effect. 2. There may be other programs that want the same treatment. I've punted here on finding more callers to convert, since "status" is the obvious one to call as a repeated background job. But "git diff"'s opportunistic refresh of the index may be a good candidate. The test is taken from 67e5ce7f63, and it's worth repeating Johannes's explanation: Note that the regression test added in this commit does not *really* verify that no index.lock file was written; that test is not possible in a portable way. Instead, we verify that .git/index is rewritten *only* when `git status` is run without `--no-optional-locks`. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27worktree: check the result of read_in_full()Libravatar Jeff King1-1/+18
We try to read "len" bytes into a buffer and just assume that it happened correctly. In practice this should usually be the case, since we just stat'd the file to get the length. But we could be fooled by transient errors or by other processes racily truncating the file. Let's be more careful. There's a slim chance this could catch a real error, but it also prevents people and tools from getting worried while reading the code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27worktree: use xsize_t to access file sizeLibravatar Jeff King1-2/+3
To read the "gitdir" file into memory, we stat the file and allocate a buffer. But we store the size in an "int", which may be truncated. We should use a size_t and xsize_t(), which will detect truncation. An overflow is unlikely for a "gitdir" file, but it's a good practice to model. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27distinguish error versus short read from read_in_full()Libravatar Jeff King3-4/+16
Many callers of read_in_full() expect to see the exact number of bytes requested, but their error handling lumps together true read errors and short reads due to unexpected EOF. We can give more specific error messages by separating these cases (showing errno when appropriate, and otherwise describing the short read). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27avoid looking at errno for short read_in_full() returnsLibravatar Jeff King2-4/+14
When a caller tries to read a particular set of bytes via read_in_full(), there are three possible outcomes: 1. An error, in which case -1 is returned and errno is set. 2. A short read, in which fewer bytes are returned and errno is unspecified (we never saw a read error, so we may have some random value from whatever syscall failed last). 3. The full read completed successfully. Many callers handle cases 1 and 2 together by just checking the result against the requested size. If their combined error path looks at errno (e.g., by calling die_errno), they may report a nonsense value. Let's fix these sites by having them distinguish between the two error cases. That avoids the random errno confusion, and lets us give more detailed error messages. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27prefer "!=" when checking read_in_full() resultLibravatar Jeff King3-3/+3
Comparing the result of read_in_full() using less-than is potentially dangerous, as a negative return value may be converted to an unsigned type and be considered a success. This is discussed further in 561598cfcf (read_pack_header: handle signed/unsigned comparison in read result, 2017-09-13). Each of these instances is actually fine in practice: - in get-tar-commit-id, the HEADERSIZE macro expands to a signed integer. If it were switched to an unsigned type (e.g., a size_t), then it would be a bug. - the other two callers check for a short read only after handling a negative return separately. This is a fine practice, but we'd prefer to model "!=" as a general rule. So all of these cases can be considered cleanups and not actual bugfixes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27string-list.h: move documentation from Documentation/api/ into headerLibravatar Han-Wen Nienhuys2-239/+162
This mirrors commit 'bdfdaa497 ("strbuf.h: integrate api-strbuf.txt documentation, 2015-01-16") which did the same for strbuf.h: * API documentation uses /** */ to set it apart from other comments. * Function names were stripped from the comments. * Ordering of the header was adjusted to follow the one from the text file. * Edited some existing comments from string-list.h for consistency. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27read_gitfile_gently: clarify return value ownership.Libravatar Han-Wen Nienhuys1-1/+2
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27real_path: clarify return value ownershipLibravatar Han-Wen Nienhuys1-0/+4
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-26Sync with 2.14.2Libravatar Junio C Hamano11-56/+183
* maint: Git 2.14.2 Git 2.13.6 Git 2.12.5 Git 2.11.4 Git 2.10.5 cvsimport: shell-quote variable used in backticks archimport: use safe_pipe_capture for user input shell: drop git-cvsserver support by default cvsserver: use safe_pipe_capture for `constant commands` as well cvsserver: use safe_pipe_capture instead of backticks cvsserver: move safe_pipe_capture() to the main package
2017-09-26submodule.c: describe submodule_to_gitdir() in a new commentLibravatar Han-Wen Nienhuys1-0/+4
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-26notes-merge: drop dead zero-write codeLibravatar Jeff King1-2/+0
We call write_in_full() with a size that we know is greater than zero. The return value can never be zero, then, since write_in_full() converts such a failed write() into ENOSPC and returns -1. We can just drop this branch of the error handling entirely. Suggested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-26files-backend: prefer "0" for write_in_full() error checkLibravatar Jeff King1-1/+1
Commit 06f46f237a (avoid "write_in_full(fd, buf, len) != len" pattern, 2017-09-13) converted this callsite from: write_in_full(...) != 1 to write_in_full(...) < 0 But during the conflict resolution in c50424a6f0 (Merge branch 'jk/write-in-full-fix', 2017-09-25), this morphed into write_in_full(...) < 1 This behaves as we want, but we prefer to avoid modeling the "less than length" error-check which can be subtly buggy, as shown in efacf609c8 (config: avoid "write_in_full(fd, buf, len) < len" pattern, 2017-09-13). Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-26Win32: simplify loading of DLL functionsLibravatar Johannes Schindelin1-0/+57
Dynamic loading of DLL functions is duplicated in several places in Git for Windows' source code. This patch adds a pair of macros to simplify the process: the DECLARE_PROC_ADDR(<dll>, <return-type>, <function-name>, ...<function-parameter-types>...) macro to be used at the beginning of a code block, and the INIT_PROC_ADDR(<function-name>) macro to call before using the declared function. The return value of the INIT_PROC_ADDR() call has to be checked; If it is NULL, the function was not found in the specified DLL. Example: DECLARE_PROC_ADDR(kernel32.dll, BOOL, CreateHardLinkW, LPCWSTR, LPCWSTR, LPSECURITY_ATTRIBUTES); if (!INIT_PROC_ADDR(CreateHardLinkW)) return error("Could not find CreateHardLinkW() function"; if (!CreateHardLinkW(source, target, NULL)) return error("could not create hardlink from %S to %S", source, target); return 0; Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25doc: camelCase the config variables to improve readabilityLibravatar Kaartic Sivaraam2-3/+3
References to multi-word configuration variable names in our documentation must consistently use camelCase to highlight where the word boundaries are, even though these are treated case insensitively. Fix a few places that spell them in all lowercase, which makes them harder to read. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25The ninth batch for 2.15Libravatar Junio C Hamano1-0/+67
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25Merge branch 'ks/test-readme-phrasofix'Libravatar Junio C Hamano1-3/+3
Doc updates. * ks/test-readme-phrasofix: t/README: fix typo and grammatically improve a sentence
2017-09-25Merge branch 'ow/rev-parse-is-shallow-repo'Libravatar Junio C Hamano3-0/+23
"git rev-parse" learned "--is-shallow-repository", that is to be used in a way similar to existing "--is-bare-repository" and friends. * ow/rev-parse-is-shallow-repo: rev-parse: rev-parse: add --is-shallow-repository
2017-09-25Merge branch 'rj/test-ulimit-on-windows'Libravatar Junio C Hamano5-40/+42
On Cygwin, "ulimit -s" does not report failure but it does not work at all, which causes an unexpected success of some tests that expect failures under a limited stack situation. This has been fixed. * rj/test-ulimit-on-windows: t9010-*.sh: skip all tests if the PIPE prereq is missing test-lib: use more compact expression in PIPE prerequisite test-lib: don't use ulimit in test prerequisites on cygwin