summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-10-03Merge branch 'sb/submodule-diff-header-fix'Libravatar Junio C Hamano2-2/+2
Error message tweak. * sb/submodule-diff-header-fix: submodule: correct error message for missing commits
2017-10-03Merge branch 'sb/diff-color-move'Libravatar Junio C Hamano7-0/+35
The output from "git diff --summary" was broken in a recent topic that has been merged to 'master' and lost a LF after reporting of mode change. This has been fixed. * sb/diff-color-move: diff: correct newline in summary for renamed files
2017-10-03Merge branch 'sb/test-submodule-update-config'Libravatar Junio C Hamano1-0/+8
* sb/test-submodule-update-config: t7406: submodule.<name>.update command must not be run from .gitmodules
2017-10-03Merge branch 'jk/validate-headref-fix'Libravatar Junio C Hamano1-11/+12
Code clean-up. * jk/validate-headref-fix: validate_headref: use get_oid_hex for detached HEADs validate_headref: use skip_prefix for symref parsing validate_headref: NUL-terminate HEAD buffer
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-28submodule: correct error message for missing commitsLibravatar Stefan Beller2-2/+2
When a submodule diff should be displayed we currently just add the submodule objects to the main object store and then e.g. walk the revision graph and create a summary for that submodule. It is possible that we are missing the submodule either completely or partially, which we currently differentiate with different error messages depending on whether (1) the whole submodule object store is missing or (2) just the needed for this particular diff. (1) is reported as "not initialized", and (2) is reported as "commits not present". If a submodule is deinit'ed its repository data is still around inside the superproject, such that the diff can still be produced. In that way the error message (1) is misleading as we can have a diff despite the submodule being not initialized. Downgrade the error message (1) to be the same as (2) and just say the commits are not present, as that is the true reason why the diff cannot be shown. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-28diff: correct newline in summary for renamed filesLibravatar Stefan Beller7-0/+35
In 146fdb0dfe (diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY, 2017-06-29), the conversion from direct printing to the symbol emission dropped the new line character for renamed, copied and rewritten files. Add the emission of a newline, add a test for this case. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-27validate_headref: use get_oid_hex for detached HEADsLibravatar Jeff King1-2/+2
If a candidate HEAD isn't a symref, we check that it contains a viable sha1. But in a post-sha1 world, we should be checking whether it has any plausible object-id. We can do that by switching to get_oid_hex(). Note that both before and after this patch, we only check for a plausible object id at the start of the file, and then call that good enough. We ignore any content _after_ the hex, so a string like: 0123456789012345678901234567890123456789 foo is accepted. Though we do put extra bytes like this into some pseudorefs (e.g., FETCH_HEAD), we don't typically do so with HEAD. We could tighten this up by using parse_oid_hex(), like: if (!parse_oid_hex(buffer, &oid, &end) && *end++ == '\n' && *end == '\0') return 0; But we're probably better to remain on the loose side. We're just checking here for a plausible-looking repository directory, so heuristics are acceptable (if we really want to be meticulous, we should use the actual ref code to parse HEAD). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27validate_headref: use skip_prefix for symref parsingLibravatar Jeff King1-9/+6
Since the previous commit guarantees that our symref buffer is NUL-terminated, we can just use skip_prefix() and friends to parse it. This is shorter and saves us having to deal with magic numbers and keeping the "len" counter up to date. While we're at it, let's name the rather obscure "buf" to "refname", since that is the thing we are parsing with it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27validate_headref: NUL-terminate HEAD bufferLibravatar Jeff King1-0/+4
When we are checking to see if we have a git repo, we peek into the HEAD file and see if it's a plausible symlink, symref, or detached HEAD. For the latter two, we read the contents with read_in_full(), which means they aren't NUL-terminated. The symref check is careful to respect the length we got, but the sha1 check will happily parse up to 40 bytes, even if we read fewer. E.g.,: echo 1234 >.git/HEAD git rev-parse will parse 36 uninitialized bytes from our stack buffer. This isn't a big deal in practice. Our buffer is 256 bytes, so we know we'll never read outside of it. The worst case is that the uninitialized bytes look like valid hex, and we claim a bogus HEAD file is valid. The chances of this happening randomly are quite slim, but let's be careful. One option would be to check that "len == 41" before feeding the buffer to get_sha1_hex(). But we'd like to eventually prepare for a world with variable-length hashes. Let's NUL-terminate as soon as we've read the buffer (we already even leave a spare byte to do so!). That fixes this problem without depending on the size of an object id. 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-27t7406: submodule.<name>.update command must not be run from .gitmodulesLibravatar Stefan Beller1-0/+8
submodule.<name>.update can be assigned an arbitrary command via setting it to "!command". When this command is found in the regular config, Git ought to just run that command instead of other update mechanisms. However if that command is just found in the .gitmodules file, it is potentially untrusted, which is why we do not run it. Add a test confirming the behavior. Suggested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> 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>