summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-09-09add -p: fix editing of intent-to-add pathsLibravatar Phillip Wood3-94/+173
A popular way of partially staging a new file is to run `git add -N <path>` and then use the hunk editing of `git add -p` to select the part of the file that the user wishes to stage. Since 85953a3187 ("diff-files --raw: show correct post-image of intent-to-add files", 2020-07-01) this has stopped working as intent-to-add paths are now show as new files rather than changes to an empty blob and `git apply` refused to apply a creation patch for a path that was marked as intent-to-add. 7cfde3fa0f ("apply: allow "new file" patches on i-t-a entries", 2020-08-06) fixed the problem with apply but it still wasn't possible to edit the added hunk properly. 2c8bd8471a ("checkout -p: handle new files correctly", 2020-05-27) had previously changed `add -p` to handle new files but it did not implement patch editing correctly. The perl version simply forbade editing and the C version opened the editor with the full diff rather that just the hunk which meant that the user had to edit the hunk header manually to get it to work. The root cause of the problem is that added files store the diff header with the hunk data rather than separating the two as we do for other changes. Changing added files to store the diff header separately fixes the editing problem at the expense of having to special case empty additions as they no longer have any hunks associated with them, only the diff header. The changes move some existing code into a conditional changing the indentation, they are best viewed with --color-moved-ws=allow-indentation-change (or --ignore-space-change works well to get an overview of the changes) Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Reported-by: Thomas Sullivan <tom@msbit.com.au> Reported-by: Yuchen Ying <ych@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-03Thirteenth batchLibravatar Junio C Hamano1-0/+26
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-03Merge branch 'pb/doc-external-diff-env'Libravatar Junio C Hamano2-3/+5
Doc update. * pb/doc-external-diff-env: git.txt: correct stale 'GIT_EXTERNAL_DIFF' description
2020-09-03Merge branch 'jk/xrealloc-avoid-use-after-free'Libravatar Junio C Hamano1-2/+5
It was possible for xrealloc() to send a non-NULL pointer that has been freed, which has been fixed. * jk/xrealloc-avoid-use-after-free: xrealloc: do not reuse pointer freed by zero-length realloc()
2020-09-03Merge branch 'jc/post-checkout-doc'Libravatar Junio C Hamano1-1/+3
Doc update. * jc/post-checkout-doc: doc: clarify how exit status of post-checkout hook is used
2020-09-03Merge branch 'pb/doc-sequence-editor-configuration'Libravatar Junio C Hamano2-0/+7
Doc update. * pb/doc-sequence-editor-configuration: doc: mention GIT_SEQUENCE_EDITOR and 'sequence.editor' more
2020-09-03Merge branch 'hl/bisect-doc-clarify-bad-good-ordering'Libravatar Junio C Hamano3-3/+3
Doc update. * hl/bisect-doc-clarify-bad-good-ordering: bisect: swap command-line options in documentation
2020-09-03Merge branch 'so/pretty-abbrev-doc'Libravatar Junio C Hamano1-2/+2
Documentation update for "--no-abbrev-commit". * so/pretty-abbrev-doc: pretty-options.txt: fix --no-abbrev-commit description
2020-09-03Merge branch 'mr/diff-hide-stat-wo-textual-change'Libravatar Junio C Hamano2-9/+67
"git diff --stat -w" showed 0-line changes for paths whose changes were only whitespaces, which was not intuitive. We now omit such paths from the stat output. * mr/diff-hide-stat-wo-textual-change: diff: teach --stat to ignore uninteresting modifications
2020-09-03Merge branch 'jt/lazy-fetch'Libravatar Junio C Hamano25-215/+278
Updates to on-demand fetching code in lazily cloned repositories. * jt/lazy-fetch: fetch: no FETCH_HEAD display if --no-write-fetch-head fetch-pack: remove no_dependents code promisor-remote: lazy-fetch objects in subprocess fetch-pack: do not lazy-fetch during ref iteration fetch: only populate existing_refs if needed fetch: avoid reading submodule config until needed fetch: allow refspecs specified through stdin negotiator/noop: add noop fetch negotiator
2020-09-03Merge branch 'jc/run-command-use-embedded-args'Libravatar Junio C Hamano4-19/+7
Various callers of run_command API has been modernized. * jc/run-command-use-embedded-args: run_command: teach API users to use embedded 'args' more
2020-09-03Merge branch 'jc/undash-in-tree-git-callers'Libravatar Junio C Hamano3-14/+14
A handful of places in in-tree code still relied on being able to execute the git subcommands, especially built-ins, in "git-foo" form, which have been corrected. * jc/undash-in-tree-git-callers: credential-cache: use child_process.args cvsexportcommit: do not run git programs in dashed form transport-helper: do not run git-remote-ext etc. in dashed form
2020-09-03Merge branch 'jk/slimmed-down'Libravatar Junio C Hamano31-3915/+80
Trim an unused binary and turn a bunch of commands into built-in. * jk/slimmed-down: drop vcs-svn experiment make git-fast-import a builtin make git-bugreport a builtin make credential helpers builtins Makefile: drop builtins from MSVC pdb list
2020-09-03Merge branch 'pw/add-p-allowed-options-fix'Libravatar Junio C Hamano1-25/+42
"git add -p" update. * pw/add-p-allowed-options-fix: add -p: fix checking of user input add -p: use ALLOC_GROW_BY instead of ALLOW_GROW
2020-09-03Merge branch 'jt/fetch-pack-loosen-validation-with-packfile-uri'Libravatar Junio C Hamano5-1/+72
Bugfix for "git fetch" when the packfile URI capability is in use. * jt/fetch-pack-loosen-validation-with-packfile-uri: fetch-pack: make packfile URIs work with transfer.fsckobjects fetch-pack: document only_packfile in get_pack() (various): document from_promisor parameter
2020-09-03Merge branch 'ss/t7401-modernize'Libravatar Junio C Hamano1-73/+76
Test clean-up. * ss/t7401-modernize: t7401: add a NEEDSWORK t7401: change indentation for enhanced readability t7401: change syntax of test_i18ncmp calls for clarity t7401: use 'short' instead of 'verify' and cut in rev-parse calls t7401: modernize style
2020-09-03Merge branch 'pw/rebase-i-more-options'Libravatar Junio C Hamano11-49/+423
"git rebase -i" learns a bit more options. * pw/rebase-i-more-options: t3436: do not run git-merge-recursive in dashed form rebase: add --reset-author-date rebase -i: support --ignore-date rebase -i: support --committer-date-is-author-date am: stop exporting GIT_COMMITTER_DATE rebase -i: add --ignore-whitespace flag
2020-09-02fetch: no FETCH_HEAD display if --no-write-fetch-headLibravatar Jonathan Tan3-11/+22
887952b8c6 ("fetch: optionally allow disabling FETCH_HEAD update", 2020-08-18) introduced the ability to disable writing to FETCH_HEAD during fetch, but did not suppress the "<source> -> FETCH_HEAD" message when this ability is used. This message is misleading in this case, because FETCH_HEAD is not written. Also, because "fetch" is used to lazy-fetch missing objects in a partial clone, this significantly clutters up the output in that case since the objects to be fetched are potentially numerous. Therefore, suppress this message when --no-write-fetch-head is passed (but not when --dry-run is set). Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-02xrealloc: do not reuse pointer freed by zero-length realloc()Libravatar Jeff King1-2/+5
This patch fixes a bug where xrealloc(ptr, 0) can double-free and corrupt the heap on some platforms (including at least glibc). The C99 standard says of malloc (section 7.20.3): If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. So we might get NULL back, or we might get an actual pointer (but we're not allowed to look at its contents). To simplify our code, our xmalloc() handles a NULL return by converting it into a single-byte allocation. That way callers get consistent behavior. This was done way back in 4e7a2eccc2 (?alloc: do not return NULL when asked for zero bytes, 2005-12-29). We also gave xcalloc() and xrealloc() the same treatment. And according to C99, that is fine; the text above is in a paragraph that applies to all three. But what happens to the memory we passed to realloc() in such a case? I.e., if we do: ret = realloc(ptr, 0); and "ptr" is non-NULL, but we get NULL back, is "ptr" still valid? C99 doesn't cover this case specifically, but says (section 7.20.3.4): The realloc function deallocates the old object pointed to by ptr and returns a pointer to a new object that has the size specified by size. So "ptr" is now deallocated, and we must only look at "ret". And since "ret" is NULL, that means we have no allocated object at all. But that's not quite the whole story. It also says: If memory for the new object cannot be allocated, the old object is not deallocated and its value is unchanged. [...] The realloc function returns a pointer to the new object (which may have the same value as a pointer to the old object), or a null pointer if the new object could not be allocated. So if we see a NULL return with a non-zero size, we can expect that the original object _is_ still valid. But with a non-zero size, it's ambiguous. The NULL return might mean a failure (in which case the object is valid), or it might mean that we successfully allocated nothing, and used NULL to represent that. The glibc manpage for realloc() explicitly says: [...]if size is equal to zero, and ptr is not NULL, then the call is equivalent to free(ptr). Likewise, this StackOverflow answer: https://stackoverflow.com/a/2135302 claims that C89 gave similar guidance (but I don't have a copy to verify it). A comment on this answer: https://stackoverflow.com/a/2022410 claims that Microsoft's CRT behaves the same. But our current "retry with 1 byte" code passes the original pointer again. So on glibc, we effectively free() the pointer and then try to realloc() it again, which is undefined behavior. The simplest fix here is to just pass "ret" (which we know to be NULL) to the follow-up realloc(). But that means that a system which _doesn't_ free the original pointer would leak it. It's not clear if any such systems exist, and that interpretation of the standard seems unlikely (I'd expect a system that doesn't deallocate to simply return the original pointer in this case). But it's easy enough to err on the safe side, and just never pass a zero size to realloc() at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-01git.txt: correct stale 'GIT_EXTERNAL_DIFF' descriptionLibravatar Philippe Blain2-3/+5
In fde97d8ac6 (Update documentation to remove incorrect GIT_DIFF_OPTS example., 2006-11-27), the description of the 'GIT_EXTERNAL_DIFF' variable was moved from 'diff-format.txt' to 'git.txt', and the documentation was updated to remove a 'diff(1)' invocation since Git did not use an external diff program anymore by default. However, the description of 'GIT_EXTERNAL_DIFF' still mentions "instead of the diff invocation described above", which is confusing. Correct that outdated sentence. Also, link to git(1) in 'diff-generate-patch.txt' when GIT_DIFF_OPTS and GIT_EXTERNAL_DIFF are mentioned, so that users can easily know what these variables are about. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31Twelfth batchLibravatar Junio C Hamano1-0/+39
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31Merge branch 'ps/ref-transaction-hook'Libravatar Junio C Hamano2-12/+12
Code simplification by removing ineffective optimization. * ps/ref-transaction-hook: refs: remove lookup cache for reference-transaction hook
2020-08-31Merge branch 'jk/rev-input-given-fix'Libravatar Junio C Hamano3-5/+26
Feeding "$ZERO_OID" to "git log --ignore-missing --stdin", and running "git log --ignore-missing $ZERO_OID" fell back to start digging from HEAD; it has been corrected to become a no-op, like "git log --tags=no-tag-matches-this-pattern" does. * jk/rev-input-given-fix: revision: set rev_input_given in handle_revision_arg()
2020-08-31Merge branch 'jc/ident-whose-ident'Libravatar Junio C Hamano2-18/+43
Error message update. * jc/ident-whose-ident: ident: say whose identity is missing when giving user.name hint
2020-08-31Merge branch 'rp/apply-cached-doc'Libravatar Junio C Hamano1-10/+10
The description of --cached/--index options in "git apply --help" has been updated. * rp/apply-cached-doc: git-apply.txt: update descriptions of --cached, --index
2020-08-31Merge branch 'rs/checkout-no-overlay-pathspec-fix'Libravatar Junio C Hamano3-3/+30
"git restore/checkout --no-overlay" with wildcarded pathspec mistakenly removed matching paths in subdirectories, which has been corrected. * rs/checkout-no-overlay-pathspec-fix: checkout, restore: make pathspec recursive
2020-08-31Merge branch 'al/bisect-first-parent'Libravatar Junio C Hamano1-1/+1
Finishing touches. * al/bisect-first-parent: bisect: add first-parent option to documentation
2020-08-31Merge branch 'jk/refspecs-cleanup'Libravatar Junio C Hamano3-13/+16
Preliminary code clean-up before introducing "negative refspec". * jk/refspecs-cleanup: refspec: make sure stack refspec_item variables are zeroed refspec: fix documentation referring to refspec_item
2020-08-31Merge branch 'hn/refs-pseudorefs'Libravatar Junio C Hamano8-48/+57
Accesses to two pseudorefs have been updated to properly use ref API. * hn/refs-pseudorefs: sequencer: treat REVERT_HEAD as a pseudo ref builtin/commit: suggest update-ref for pseudoref removal sequencer: treat CHERRY_PICK_HEAD as a pseudo ref refs: make refs_ref_exists public
2020-08-31Merge branch 'jk/index-pack-w-more-threads'Libravatar Junio C Hamano4-26/+51
Long ago, we decided to use 3 threads by default when running the index-pack task in parallel, which has been adjusted a bit upwards. * jk/index-pack-w-more-threads: index-pack: adjust default threading cap p5302: count up to online-cpus for thread tests p5302: disable thread-count parameter tests by default
2020-08-31Merge branch 'hv/ref-filter-trailers-atom-parsing-fix'Libravatar Junio C Hamano2-41/+23
The parser for "git for-each-ref --format=..." was too loose when parsing the "%(trailers...)" atom, and forgot that "trailers" and "trailers:<modifiers>" are the only two allowed forms, which has been corrected. * hv/ref-filter-trailers-atom-parsing-fix: ref-filter: 'contents:trailers' show error if `:` is missing t6300: unify %(trailers) and %(contents:trailers) tests
2020-08-31Merge branch 'jt/promisor-pack-fix'Libravatar Junio C Hamano2-7/+26
Updates into a lazy/partial clone with a submodule did not work well with transfer.fsckobjects set. * jt/promisor-pack-fix: fetch-pack: in partial clone, pass --promisor
2020-08-31Merge branch 'dd/diff-customize-index-line-abbrev'Libravatar Junio C Hamano6-26/+138
The output from the "diff" family of the commands had abbreviated object names of blobs involved in the patch, but its length was not affected by the --abbrev option. Now it is. * dd/diff-customize-index-line-abbrev: diff: index-line: respect --abbrev in object's name t4013: improve diff-post-processor logic
2020-08-31Merge branch 'am/ci-wsfix'Libravatar Junio C Hamano1-28/+28
Aesthetic fix to a CI configuration file. * am/ci-wsfix: ci: fix inconsistent indentation
2020-08-31doc: mention GIT_SEQUENCE_EDITOR and 'sequence.editor' moreLibravatar Philippe Blain2-0/+7
The environment variable `GIT_SEQUENCE_EDITOR`, and the configuration variable 'sequence.editor', which were added in 821881d88d ("rebase -i": support special-purpose editor to edit insn sheet, 2011-10-17), are mentioned in the `git config` man page but not anywhere else. Include `config/sequencer.txt` in `git-rebase.txt`, so that both the environment variable and the configuration setting are mentioned there. Also, add `GIT_SEQUENCE_EDITOR` to the list of environment variables in `git(1)`. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-28bisect: swap command-line options in documentationLibravatar Hugo Locurcio3-3/+3
The positional arguments are specified in this order: "bad" then "good". To avoid confusion, the options above the positional arguments are now specified in the same order. They can still be specified in any order since they're options, not positional arguments. Signed-off-by: Hugo Locurcio <hugo.locurcio@hugo.pro> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-28po: add missing letter for French messageLibravatar brian m. carlson1-1/+1
Add the missing "e" in "de". While it is possible in French to omit it, that only occurs with an apostrophe and only when the next word starts with a vowel or mute h, which is not the case here. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27doc: clarify how exit status of post-checkout hook is usedLibravatar Junio C Hamano1-1/+3
Because the hook runs after the main checkout operation finishes, it cannot affect what branch will be the current branch, what paths are updated in the working tree, etc., which was described as "cannot affect the outcome of 'checkout'". However, the exit status of the hook is used as the exit status of the 'checkout' command and is observable by anybody who spawned the 'checkout', which was missing from the documentation. Fix this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27Eleventh batchLibravatar Junio C Hamano1-0/+9
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27Merge branch 'hn/refs-fetch-head-is-special'Libravatar Junio C Hamano4-26/+63
The FETCH_HEAD is now always read from the filesystem regardless of the ref backend in use, as its format is much richer than the normal refs, and written directly by "git fetch" as a plain file.. * hn/refs-fetch-head-is-special: refs: read FETCH_HEAD and MERGE_HEAD generically refs: move gitdir into base ref_store refs: fix comment about submodule ref_stores refs: split off reading loose ref data in separate function
2020-08-27Merge branch 'rz/complete-more-options'Libravatar Junio C Hamano2-10/+30
Command line completion (in contrib/) usually omits redundant, deprecated and/or dangerous options from its output; it learned to optionally include all of them. * rz/complete-more-options: completion: add GIT_COMPLETION_SHOW_ALL env var parse-options: add --git-completion-helper-all
2020-08-27Merge branch 'jk/leakfix'Libravatar Junio C Hamano17-52/+69
Code clean-up. * jk/leakfix: submodule--helper: fix leak of core.worktree value config: fix leak in git_config_get_expiry_in_days() config: drop git_config_get_string_const() config: fix leaks from git_config_get_string_const() checkout: fix leak of non-existent branch names submodule--helper: use strbuf_release() to free strbufs clear_pattern_list(): clear embedded hashmaps
2020-08-27Merge branch 'en/mem-pool'Libravatar Junio C Hamano5-52/+70
API update. * en/mem-pool: mem-pool: use consistent pool variable name mem-pool: use more standard initialization and finalization mem-pool: add convenience functions for strdup and strndup
2020-08-27pretty-options.txt: fix --no-abbrev-commit descriptionLibravatar Sergey Organov1-2/+2
Description suggested --no-abbrev-commit negates --oneline as well as any other option that implies --abbrev-commit. Fix it to say that it's --abbrev-commit that is negated, not the option that implies it. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27credential-cache: use child_process.argsLibravatar Junio C Hamano1-4/+4
As child_process structure has an embedded strvec args for formulating the command line, let's use it instead of using an out-of-line argv[] whose length needs to be maintained correctly. Also, when spawning a git subcommand, omit it from the command list and instead use the .git_cmd bit in the child_process structure. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-26run_command: teach API users to use embedded 'args' moreLibravatar Junio C Hamano4-19/+7
The child_process structure has an embedded strvec for formulating the command line argument list these days, but code that predates the wide use of it prepared a separate char *argv[] array and manually set the child_process.argv pointer point at it. Teach these old-style code to lose the separate argv[] array. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-26cvsexportcommit: do not run git programs in dashed formLibravatar Junio C Hamano1-8/+8
This ancient script runs "git-foo" all over the place, which is OK for a scripted Porcelain in the Git suite, but asking "git" to dispatch to subcommands is the usual way these days. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-26transport-helper: do not run git-remote-ext etc. in dashed formLibravatar Junio C Hamano1-2/+2
Running it as "git remote-ext" and letting "git" dispatch to "remote-ext" would just be fine and is more idiomatic. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-26t3436: do not run git-merge-recursive in dashed formLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-26revision: set rev_input_given in handle_revision_arg()Libravatar Jeff King3-5/+26
Commit 7ba826290a (revision: add rev_input_given flag, 2017-08-02) added a flag to rev_info to tell whether we got any revision arguments. As explained there, this is necessary because some revision arguments may not produce any pending traversal objects, but should still inhibit default behaviors (e.g., a glob that matches nothing). However, it only set the flag in the globbing code, but not for revisions we get on the command-line or via stdin. This leads to two problems: - the command-line code keeps its own separate got_rev_arg flag; this isn't wrong, but it's confusing and an extra maintenance burden - even specifically-named rev arguments might end up not adding any pending objects: if --ignore-missing is set, then specifying a missing object is a noop rather than an error. And that leads to some user-visible bugs: - when deciding whether a default rev like "HEAD" should kick in, we check both got_rev_arg and rev_input_given. That means that "--ignore-missing $ZERO_OID" works on the command-line (where we set got_rev_arg) but not on --stdin (where we don't) - when rev-list decides whether it should complain that it wasn't given a starting point, it relies on rev_input_given. So it can't even get the command-line "--ignore-missing $ZERO_OID" right Let's consistently set the flag if we got any revision argument. That lets us clean up the redundant got_rev_arg, and fixes both of those bugs (but note there are three new tests: we'll confirm the already working git-log command-line case). A few implementation notes: - conceptually we want to set the flag whenever handle_revision_arg() finds an actual revision arg ("handles" it, you might say). But it covers a ton of cases with early returns. Rather than annotating each one, we just wrap it and use its success exit-code to set the flag in one spot. - the new rev-list test is in t6018, which is titled to cover globs. This isn't exactly a glob, but it made sense to stick it with the other tests that handle the "even though we got a rev, we have no pending objects" case, which are globs. - the tests check for the oid of a missing object, which it's pretty clear --ignore-missing should ignore. You can see the same behavior with "--ignore-missing a-ref-that-does-not-exist", because --ignore-missing treats them both the same. That's perhaps less clearly correct, and we may want to change that in the future. But the way the code and tests here are written, we'd continue to do the right thing even if it does. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>