summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2019-06-21Merge branch 'jt/partial-clone-missing-ref-delta-base'Libravatar Junio C Hamano1-2/+24
"git fetch" into a lazy clone forgot to fetch base objects that are necessary to complete delta in a thin packfile, which has been corrected. * jt/partial-clone-missing-ref-delta-base: t5616: cover case of client having delta base t5616: use correct flag to check object is missing index-pack: prefetch missing REF_DELTA bases t5616: refactor packfile replacement
2019-06-17Merge branch 'xl/record-partial-clone-origin'Libravatar Junio C Hamano1-1/+1
When creating a partial clone, the object filtering criteria is recorded for the origin of the clone, but this incorrectly used a hardcoded name "origin" to name that remote; it has been corrected to honor the "--origin <name>" option. * xl/record-partial-clone-origin: clone: respect user supplied origin name when setting up partial clone
2019-06-17Merge branch 'js/fsmonitor-unflake'Libravatar Junio C Hamano1-1/+1
The data collected by fsmonitor was not properly written back to the on-disk index file, breaking t7519 tests occasionally, which has been corrected. * js/fsmonitor-unflake: mark_fsmonitor_valid(): mark the index as changed if needed fill_stat_cache_info(): prepare for an fsmonitor fix
2019-06-17Merge branch 'ba/clone-remote-submodules'Libravatar Junio C Hamano1-0/+8
"git clone --recurse-submodules" learned to set up the submodules to ignore commit object names recorded in the superproject gitlink and instead use the commits that happen to be at the tip of the remote-tracking branches from the get-go, by passing the new "--remote-submodules" option. * ba/clone-remote-submodules: clone: add `--remote-submodules` flag
2019-06-17Merge branch 'vv/merge-squash-with-explicit-commit'Libravatar Junio C Hamano1-1/+11
"git merge --squash" is designed to update the working tree and the index without creating the commit, and this cannot be countermanded by adding the "--commit" option; the command now refuses to work when both options are given. * vv/merge-squash-with-explicit-commit: merge: refuse --commit with --squash
2019-06-17Merge branch 'js/bisect-helper-check-get-oid-return-value'Libravatar Junio C Hamano1-1/+4
Code cleanup. * js/bisect-helper-check-get-oid-return-value: bisect--helper: verify HEAD could be parsed before continuing
2019-06-17Merge branch 'jk/am-i-resolved-fix'Libravatar Junio C Hamano1-11/+12
"git am -i --resolved" segfaulted after trying to see a commit as if it were a tree, which has been corrected. * jk/am-i-resolved-fix: am: fix --interactive HEAD tree resolution am: drop tty requirement for --interactive am: read interactive input from stdin am: simplify prompt response handling
2019-06-13Merge branch 'dl/format-patch-notes-config'Libravatar Junio C Hamano1-1/+19
"git format-patch" learns a configuration to set the default for its --notes=<ref> option. * dl/format-patch-notes-config: format-patch: teach format.notes config option git-format-patch.txt: document --no-notes option
2019-06-13Merge branch 'nd/merge-quit'Libravatar Junio C Hamano1-12/+18
"git merge" learned "--quit" option that cleans up the in-progress merge while leaving the working tree and the index still in a mess. * nd/merge-quit: merge: add --quit merge: remove drop_save() in favor of remove_merge_branch_state()
2019-06-13Merge branch 'js/rebase-cleanup'Libravatar Junio C Hamano1-6/+1
Update supporting parts of "git rebase" to remove code that should no longer be used. * js/rebase-cleanup: rebase: fold git-rebase--common into the -p backend sequencer: the `am` and `rebase--interactive` scripts are gone .gitignore: there is no longer a built-in `git-rebase--interactive` t3400: stop referring to the scripted rebase Drop unused git-rebase--am.sh
2019-06-13Merge branch 'nd/worktree-name-sanitization'Libravatar Junio C Hamano1-1/+9
In recent versions of Git, per-worktree refs are exposed in refs/worktrees/<wtname>/ hierarchy, which means that worktree names must be a valid refname component. The code now sanitizes the names given to worktrees, to make sure these refs are well-formed. * nd/worktree-name-sanitization: worktree add: sanitize worktree names
2019-06-13Merge branch 'en/fast-export-encoding'Libravatar Junio C Hamano1-6/+49
The "git fast-export/import" pair has been taught to handle commits with log messages in encoding other than UTF-8 better. * en/fast-export-encoding: fast-export: do automatic reencoding of commit messages only if requested fast-export: differentiate between explicitly UTF-8 and implicitly UTF-8 fast-export: avoid stripping encoding header if we cannot reencode fast-import: support 'encoding' commit header t9350: fix encoding test to actually test reencoding
2019-06-13Merge branch 'jk/unused-params-final-batch'Libravatar Junio C Hamano18-58/+44
* jk/unused-params-final-batch: verify-commit: simplify parameters to run_gpg_verify() show-branch: drop unused parameter from show_independent() rev-list: drop unused void pointer from finish_commit() remove_all_fetch_refspecs(): drop unused "remote" parameter receive-pack: drop unused "commands" from prepare_shallow_update() pack-objects: drop unused rev_info parameters name-rev: drop unused parameters from is_better_name() mktree: drop unused length parameter wt-status: drop unused status parameter read-cache: drop unused parameter from threaded load clone: drop dest parameter from copy_alternates() submodule: drop unused prefix parameter from some functions builtin: consistently pass cmd_* prefix to parse_options cmd_{read,write}_tree: rename "unused" variable that is used
2019-06-13Merge branch 'sb/format-patch-base-patch-id-fix'Libravatar Junio C Hamano2-17/+2
The "--base" option of "format-patch" computed the patch-ids for prerequisite patches in an unstable way, which has been updated to compute in a way that is compatible with "git patch-id --stable". * sb/format-patch-base-patch-id-fix: format-patch: make --base patch-id output stable format-patch: inform user that patch-id generation is unstable
2019-06-13Merge branch 'nd/init-relative-template-fix'Libravatar Junio C Hamano1-0/+3
A relative pathname given to "git init --template=<path> <repo>" ought to be relative to the directory "git init" gets invoked in, but it instead was made relative to the repository, which has been corrected. * nd/init-relative-template-fix: init: make --template path relative to $CWD
2019-05-30Merge branch 'js/rebase-config-bitfix'Libravatar Junio C Hamano1-1/+1
* js/rebase-config-bitfix: rebase: replace incorrect logical negation by correct bitwise one
2019-05-29clone: respect user supplied origin name when setting up partial cloneLibravatar Xin Li1-1/+1
Signed-off-by: Xin Li <delphij@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28fill_stat_cache_info(): prepare for an fsmonitor fixLibravatar Johannes Schindelin1-1/+1
We will need to pass down the `struct index_state` to `mark_fsmonitor_valid()` for an upcoming bug fix, and this here function calls that there function, so we need to extend the signature of `fill_stat_cache_info()` first. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28merge: refuse --commit with --squashLibravatar Vishal Verma1-1/+11
Convert option_commit to tristate, representing the states of 'default/untouched', 'enabled-by-cli', 'disabled-by-cli'. With this in place, check whether option_commit was enabled by cli when squashing a merge. If so, error out, as this is not supported. Previously, when --squash was supplied, 'option_commit' was silently dropped. This could have been surprising to a user who tried to override the no-commit behavior of squash using --commit explicitly. Add a note to the --squash option for git-merge to clarify the incompatibility, and add a test case to t7600-merge.sh Cc: Junio C Hamano <gitster@pobox.com> Cc: Rafael Ascensão <rafa.almas@gmail.com> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Vishal Verma <vishal@stellar.sh> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28bisect--helper: verify HEAD could be parsed before continuingLibravatar Johannes Schindelin1-1/+4
In 06f5608c14e6 (bisect--helper: `bisect_start` shell function partially in C, 2019-01-02), we introduced a call to `get_oid()` and did not check whether it succeeded before using its output. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28rebase: replace incorrect logical negation by correct bitwise oneLibravatar Johannes Schindelin1-1/+1
In bff014dac7d9 (builtin rebase: support the `verbose` and `diffstat` options, 2018-09-04), we added a line that wanted to remove the `REBASE_DIFFSTAT` bit from the flags, but it used an incorrect negation. Found by Coverity. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28am: fix --interactive HEAD tree resolutionLibravatar Jeff King1-3/+4
In --interactive mode, "git am --resolved" will try to generate a patch based on what is in the index, so that it can prompt "apply this patch?". To do so it needs the tree of HEAD, which it tries to get with get_oid_tree(). However, this doesn't yield a tree object; the "tree" part just means "if you must disambiguate short oids, then prefer trees" (and we do not need to disambiguate at all, since we are feeding a ref). Instead, we must parse the oid as a commit (which should always be true in a non-corrupt repository), and access its tree pointer manually. This has been broken since the conversion to C in 7ff2683253 (builtin-am: implement -i/--interactive, 2015-08-04), but there was no test coverage because of interactive-mode's insistence on having a tty. That was lifted in the previous commit, so we can now add a test for this case. Note that before this patch, the test would result in a BUG() which comes from 3506dc9445 (has_uncommitted_changes(): fall back to empty tree, 2018-07-11). But before that, we'd have simply segfaulted (and in fact this is the exact type of case the BUG() added there was trying to catch!). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28am: drop tty requirement for --interactiveLibravatar Jeff King1-3/+3
We have required that the stdin of "am --interactive" be a tty since a1451104ac (git-am: interactive should fail gracefully., 2005-10-12). However, this isn't strictly necessary, and makes the tool harder to test (and is unlike all of our other --interactive commands). The goal of that commit was to make sure that somebody does not do: git am --interactive <mbox and cause us to read commands from the mbox. But we can simply check up front for this case and complain before entering the interactive loop. Technically this disallows: git am --interactive </dev/null where our lack of patches means we would never prompt for anything, and so the old code would not notice our lack of tty (and now we'd die early). But since such a command is totally pointless, it's no loss. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28am: read interactive input from stdinLibravatar Jeff King1-2/+4
In the conversion of git-am from shell script to C, we switched to using git_prompt(). Unlike the original shell command "read reply", this doesn't read from stdin at all, but rather from /dev/tty. In most cases this distinction wouldn't matter. We require (as the shell script did) that stdin is a tty, so they would generally be the same thing. But one important exception is our test suite: even with test_terminal, we cannot test "am --interactive" because it insists on reading from /dev/tty, not the pseudo-tty we've set up in the test script. Fixing this clears the way to adding tests in a future patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28am: simplify prompt response handlingLibravatar Jeff King1-3/+1
We'll never see a NULL returned from git_prompt(); if it can't produce any input for us (e.g., because the terminal got EOF) then it will just die(). So there's no need for us to handle NULL here. And even if there was, it doesn't make sense to continue; on a true terminal hangup we'd just loop infinitely trying to get input that will never come. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28clone: add `--remote-submodules` flagLibravatar Ben Avison1-0/+8
When using `git clone --recurse-submodules` there was previously no way to pass a `--remote` switch to the implicit `git submodule update` command for any use case where you want the submodules to be checked out on their remote-tracking branch rather than with the SHA-1 recorded in the superproject. This patch rectifies this situation. It actually passes `--no-fetch` to `git submodule update` as well on the grounds they the submodule has only just been cloned, so fetching from the remote again only serves to slow things down. Signed-off-by: Ben Avison <bavison@riscosopen.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19Merge branch 'js/difftool-no-index'Libravatar Junio C Hamano1-1/+2
The "--dir-diff" mode of "git difftool" is not useful in "--no-index" mode; they are now explicitly marked as mutually incompatible. * js/difftool-no-index: difftool --no-index: error out on --dir-diff (and don't crash)
2019-05-19Merge branch 'ds/midx-too-many-packs'Libravatar Junio C Hamano2-2/+2
The code to generate the multi-pack idx file was not prepared to see too many packfiles and ran out of open file descriptor, which has been corrected. * ds/midx-too-many-packs: midx: add packs to packed_git linked list midx: pass a repository pointer
2019-05-19Merge branch 'en/unicode-in-refnames'Libravatar Junio C Hamano2-0/+5
On a filesystem like HFS+, the names of the refs stored as filesystem entities may become different from what the end-user expects, just like files in the working tree get "renamed". Work around the mismatch by paying attention to the core.precomposeUnicode configuration. * en/unicode-in-refnames: Honor core.precomposeUnicode in more places
2019-05-19Merge branch 'dl/difftool-mergetool'Libravatar Junio C Hamano1-8/+5
Update "git difftool" and "git mergetool" so that the combinations of {diff,merge}.{tool,guitool} configuration variables serve as fallback settings of each other in a sensible order. * dl/difftool-mergetool: difftool: fallback on merge.guitool difftool: make --gui, --tool and --extcmd mutually exclusive mergetool: fallback to tool when guitool unavailable mergetool--lib: create gui_mode function mergetool: use get_merge_tool function t7610: add mergetool --gui tests t7610: unsuppress output
2019-05-19Merge branch 'nd/parse-options-aliases'Libravatar Junio C Hamano1-4/+1
Attempt to use an abbreviated option in "git clone --recurs" is responded by a request to disambiguate between --recursive and --recurse-submodules, which is bad because these two are synonyms. The parse-options API has been extended to define such synonyms more easily and not produce an unnecessary failure. * nd/parse-options-aliases: parse-options: don't emit "ambiguous option" for aliases
2019-05-19Merge branch 'nd/submodule-helper-incomplete-line-fix'Libravatar Junio C Hamano1-1/+1
Typofix. * nd/submodule-helper-incomplete-line-fix: submodule--helper: add a missing \n
2019-05-19Merge branch 'dl/warn-tagging-a-tag'Libravatar Junio C Hamano1-1/+1
Typofix. * dl/warn-tagging-a-tag: tag: fix typo in nested tagging hint
2019-05-19merge: add --quitLibravatar Nguyễn Thái Ngọc Duy1-0/+13
This allows to cancel the current merge without resetting worktree/index, which is what --abort is for. Like other --quit(s), this is often used when you forgot that you're in the middle of a merge and already switched away, doing different things. By the time you've realized, you can't even continue the merge anymore. This also makes all in-progress commands, am, merge, rebase, revert and cherry-pick, take all three --abort, --continue and --quit (bisect has a different UI). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-17format-patch: teach format.notes config optionLibravatar Denton Liu1-1/+19
In git-format-patch, notes can be appended with the `--notes` option. However, this must be specified by the user on an invocation-by-invocation basis. If a user is not careful, it's possible that they may forget to include it and generate a patch series without notes. Teach git-format-patch the `format.notes` config option. Its value is a notes ref that will be automatically appended. The special value of "standard" can be used to specify the standard notes. This option is overridable with the `--no-notes` option in case a user wishes not to append notes. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-15worktree add: sanitize worktree namesLibravatar Nguyễn Thái Ngọc Duy1-1/+9
Worktree names are based on $(basename $GIT_WORK_TREE). They aren't significant until 3a3b9d8cde (refs: new ref types to make per-worktree refs visible to all worktrees - 2018-10-21), where worktree name could be part of a refname and must follow refname rules. Update 'worktree add' code to remove special characters to follow these rules. In the future the user will be able to specify the worktree name by themselves if they're not happy with this dumb character substitution. Reported-by: Konstantin Kharlamov <hi-angel@yandex.ru> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-15index-pack: prefetch missing REF_DELTA basesLibravatar Jonathan Tan1-2/+24
When fetching, the client sends "have" commit IDs indicating that the server does not need to send any object referenced by those commits, reducing network I/O. When the client is a partial clone, the client still sends "have"s in this way, even if it does not have every object referenced by a commit it sent as "have". If a server omits such an object, it is fine: the client could lazily fetch that object before this fetch, and it can still do so after. The issue is when the server sends a thin pack containing an object that is a REF_DELTA against such a missing object: index-pack fails to fix the thin pack. When support for lazily fetching missing objects was added in 8b4c0103a9 ("sha1_file: support lazily fetching missing objects", 2017-12-08), support in index-pack was turned off in the belief that it accesses the repo only to do hash collision checks. However, this is not true: it also needs to access the repo to resolve REF_DELTA bases. Support for lazy fetching should still generally be turned off in index-pack because it is used as part of the lazy fetching process itself (if not, infinite loops may occur), but we do need to fetch the REF_DELTA bases. (When fetching REF_DELTA bases, it is unlikely that those are REF_DELTA themselves, because we do not send "have" when making such fetches.) To resolve this, prefetch all missing REF_DELTA bases before attempting to resolve them. This both ensures that all bases are attempted to be fetched, and ensures that we make only one request per index-pack invocation, and not one request per missing object. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-15rebase: fold git-rebase--common into the -p backendLibravatar Johannes Schindelin1-2/+1
The only remaining scripted part of `git rebase` is the `--preserve-merges` backend. Meaning: there is little reason to keep the "library of common rebase functions" as a separate file. While moving the functions to `git-rebase--preserve-merges.sh`, we also drop the `move_to_original_branch` function that is no longer used. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-15Drop unused git-rebase--am.shLibravatar Johannes Schindelin1-4/+0
Since 21853626ea (built-in rebase: call `git am` directly, 2019-01-18), the built-in rebase already uses the built-in `git am` directly. Now that d03ebd411c (rebase: remove the rebase.useBuiltin setting, 2019-03-18) even removed the scripted rebase, there is no longer any user of `git-rebase--am.sh`, so let's just remove it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-14fast-export: do automatic reencoding of commit messages only if requestedLibravatar Elijah Newren1-3/+43
Automatic re-encoding of commit messages (and dropping of the encoding header) hurts attempts to do reversible history rewrites (e.g. sha1sum <-> sha256sum transitions, some subtree rewrites), and seems inconsistent with the general principle followed elsewhere in fast-export of requiring explicit user requests to modify the output (e.g. --signed-tags=strip, --tag-of-filtered-object=rewrite). Add a --reencode flag that the user can use to specify, and like other fast-export flags, default it to 'abort'. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-14fast-export: differentiate between explicitly UTF-8 and implicitly UTF-8Libravatar Elijah Newren1-1/+1
The find_encoding() function returned the encoding used by a commit message, returning a default of git_commit_encoding (usually UTF-8). Although the current code does not differentiate between a commit which explicitly requested UTF-8 and one where we just assume UTF-8 because no encoding is set, it will become important when we try to preserve the encoding header. Since is_encoding_utf8() returns true when passed NULL, we can just return NULL from find_encoding() instead of returning git_commit_encoding. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-14fast-export: avoid stripping encoding header if we cannot reencodeLibravatar Elijah Newren1-2/+5
When fast-export encounters a commit with an 'encoding' header, it tries to reencode in UTF-8 and then drops the encoding header. However, if it fails to reencode in UTF-8 because e.g. one of the characters in the commit message was invalid in the old encoding, then we need to retain the original encoding or otherwise we lose information needed to understand all the other (valid) characters in the original commit message. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13Merge branch 'pw/clean-sequencer-state-upon-final-commit'Libravatar Junio C Hamano1-2/+1
"git chery-pick" (and "revert" that shares the same runtime engine) that deals with multiple commits got confused when the final step gets stopped with a conflict and the user concluded the sequence with "git commit". Attempt to fix it by cleaning up the state files used by these commands in such a situation. * pw/clean-sequencer-state-upon-final-commit: fix cherry-pick/revert status after commit commit/reset: try to clean up sequencer state
2019-05-13Merge branch 'pw/rebase-i-internal'Libravatar Junio C Hamano2-490/+465
The internal implementation of "git rebase -i" has been updated to avoid forking a separate "rebase--interactive" process. * pw/rebase-i-internal: rebase -i: run without forking rebase--interactive rebase: use a common action enum rebase -i: use struct rebase_options in do_interactive_rebase() rebase -i: use struct rebase_options to parse args rebase -i: use struct object_id for squash_onto rebase -i: use struct commit when parsing options rebase -i: remove duplication rebase -i: combine rebase--interactive.c with rebase.c rebase: use OPT_RERERE_AUTOUPDATE() rebase: rename write_basic_state() rebase: don't translate trace strings sequencer: always discard index after checkout
2019-05-13Merge branch 'ew/repack-with-bitmaps-by-default'Libravatar Junio C Hamano2-2/+5
The connectivity bitmaps are created by default in bare repositories now; also the pathname hash-cache is created by default to avoid making crappy deltas when repacking. * ew/repack-with-bitmaps-by-default: pack-objects: default to writing bitmap hash-cache t5310: correctly remove bitmaps for jgit test repack: enable bitmaps by default on bare repos
2019-05-13Merge branch 'js/partial-clone-connectivity-check'Libravatar Junio C Hamano1-2/+4
During an initial "git clone --depth=..." partial clone, it is pointless to spend cycles for a large portion of the connectivity check that enumerates and skips promisor objects (which by definition is all objects fetched from the other side). This has been optimized out. * js/partial-clone-connectivity-check: t/perf: add perf script for partial clones clone: do faster object check for partial clones
2019-05-13difftool: fallback on merge.guitoolLibravatar Denton Liu1-8/+2
In git-difftool.txt, it says 'git difftool' falls back to 'git mergetool' config variables when the difftool equivalents have not been defined. However, when `diff.guitool` is missing, it doesn't fallback to anything. Make git-difftool fallback to `merge.guitool` when `diff.guitool` is missing. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13difftool: make --gui, --tool and --extcmd mutually exclusiveLibravatar Denton Liu1-0/+3
In git-difftool, these options specify which tool to ultimately run. As a result, they are logically conflicting. Explicitly disallow these options from being used together. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13init: make --template path relative to $CWDLibravatar Nguyễn Thái Ngọc Duy1-0/+3
During git-init we chdir() to the target directory, but --template is not adjusted. So it's relative to the target directory instead of current directory. It would be ok if it's documented, but --template in git-init.txt mentions nothing about this behavior. Change it to be relative to $CWD, which is much more intuitive. The changes in the test suite show that this relative-to-target behavior is actually used. I just hope that it's only used in the test suite and it's safe to change. Otherwise, the other option is just document it (i.e. relative to target dir) and move on. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13verify-commit: simplify parameters to run_gpg_verify()Libravatar Jeff King1-15/+8
The buf/len parameters of run_gpg_verify() have never been used since the function was added in d07b00b7f3 (verify-commit: scriptable commit signature verification, 2014-06-23). Instead, check_commit_signature() accesses the commit struct directly. Worse, we read the whole object just to check its type and do not attach it to the "struct commit". Meaning we end up loading the object from disk twice for no good reason. And to further confuse matters, our type check is comes from what we read from disk, but we later assume that lookup_commit() will return non-NULL. This might not be true if some other object previously referenced the same oid as a non-commit (though this may be impossible to trigger in practice since we don't generally parse any other objects in this command). Instead, let's do our type check by loading the object via parse_object(). That will attach the buffer to the struct so it can be used later by check_commit_signature(). And it ensures that lookup_commit() will return something sane. And then we can just drop the unused "buf" and "len" parameters entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>