summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2021-12-10Merge branch 'mp/absorb-submodule-git-dir-upon-deinit'Libravatar Junio C Hamano1-10/+11
"git submodule deinit" for a submodule whose .git metadata directory is embedded in its working tree refused to work, until the submodule gets converted to use the "absorbed" form where the metadata directory is stored in superproject, and a gitfile at the top-level of the working tree of the submodule points at it. The command is taught to convert such submodules to the absorbed form as needed. * mp/absorb-submodule-git-dir-upon-deinit: submodule: absorb git dir instead of dying on deinit
2021-12-10Merge branch 'hn/create-reflog-simplify'Libravatar Junio C Hamano1-1/+1
A small simplification of API. * hn/create-reflog-simplify: refs: drop force_create argument of create_reflog API
2021-12-10Merge branch 'vd/sparse-reset'Libravatar Junio C Hamano1-6/+107
Various operating modes of "git reset" have been made to work better with the sparse index. * vd/sparse-reset: unpack-trees: improve performance of next_cache_entry reset: make --mixed sparse-aware reset: make sparse-aware (except --mixed) reset: integrate with sparse index reset: expand test coverage for sparse checkouts sparse-index: update command for expand/collapse test reset: preserve skip-worktree bit in mixed reset reset: rename is_missing to !is_in_reset_tree
2021-12-10Merge branch 'po/size-t-for-vs'Libravatar Junio C Hamano1-1/+1
On platforms where ulong is shorter than size_t, code paths that shifted 1 or 1U to the left lacked the necessary cast to size_t, which have been corrected. * po/size-t-for-vs: object-file.c: LLP64 compatibility, upcast unity for left shift diffcore-delta.c: LLP64 compatibility, upcast unity for left shift repack.c: LLP64 compatibility, upcast unity for left shift
2021-12-10Merge branch 'ah/advice-pull-has-no-preference-between-rebase-and-merge'Libravatar Junio C Hamano1-1/+1
The advice message given by "git pull" when the user hasn't made a choice between merge and rebase still said that the merge is the default, which no longer is the case. This has been corrected. * ah/advice-pull-has-no-preference-between-rebase-and-merge: pull: don't say that merge is "the default strategy"
2021-12-10Merge branch 'ab/checkout-branch-info-leakfix'Libravatar Junio C Hamano1-31/+55
Leakfix. * ab/checkout-branch-info-leakfix: checkout: fix "branch info" memory leaks
2021-12-10Merge branch 'tw/var-default-branch'Libravatar Junio C Hamano1-0/+7
"git var GIT_DEFAULT_BRANCH" is a way to see what name is used for the newly created branch if "git init" is run. * tw/var-default-branch: var: add GIT_DEFAULT_BRANCH variable
2021-12-10Merge branch 'ja/doc-cleanup'Libravatar Junio C Hamano1-1/+1
Doc update. * ja/doc-cleanup: init doc: --shared=0xxx does not give umask but perm bits doc: git-init: clarify file modes in octal. doc: git-http-push: describe the refs as pattern pairs doc: uniformize <URL> placeholders' case doc: use three dots for indicating repetition instead of star doc: git-ls-files: express options as optional alternatives doc: use only hyphens as word separators in placeholders doc: express grammar placeholders between angle brackets doc: split placeholders as individual tokens doc: fix git credential synopsis
2021-12-01repack.c: LLP64 compatibility, upcast unity for left shiftLibravatar Philip Oakley1-1/+1
Visual Studio reports C4334 "was 64-bit shift intended" warning because of size mismatch. Promote unity to the matching type to fit with the `&` operator. Signed-off-by: Philip Oakley <philipoakley@iee.email> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-29Merge branch 'tb/plug-pack-bitmap-leaks'Libravatar Junio C Hamano3-5/+14
Leakfix. * tb/plug-pack-bitmap-leaks: pack-bitmap.c: more aggressively free in free_bitmap_index() pack-bitmap.c: don't leak type-level bitmaps midx.c: write MIDX filenames to strbuf builtin/multi-pack-index.c: don't leak concatenated options builtin/repack.c: avoid leaking child arguments builtin/pack-objects.c: don't leak memory via arguments t/helper/test-read-midx.c: free MIDX within read_midx_file() midx.c: don't leak MIDX from verify_midx_file midx.c: clean up chunkfile after reading the MIDX
2021-11-29Merge branch 'jc/fix-ref-sorting-parse'Libravatar Junio C Hamano4-23/+24
Things like "git -c branch.sort=bogus branch new HEAD", i.e. the operation modes of the "git branch" command that do not need the sort key information, no longer errors out by seeing a bogus sort key. * jc/fix-ref-sorting-parse: for-each-ref: delay parsing of --sort=<atom> options
2021-11-29Merge branch 'so/stash-staged'Libravatar Junio C Hamano1-9/+71
"git stash" learned the "--staged" option to stash away what has been added to the index (and nothing else). * so/stash-staged: stash: get rid of unused argument in stash_staged() stash: implement '--staged' option for 'push' and 'save'
2021-11-29reset: make --mixed sparse-awareLibravatar Victoria Dye1-2/+85
Remove the `ensure_full_index` guard on `read_from_tree` and update `git reset --mixed` to ensure it can use sparse directory index entries wherever possible. Sparse directory entries are reset using `diff_tree_oid`, which requires `change` and `add_remove` functions to process the internal contents of the sparse directory. The `recursive` diff option handles cases in which `reset --mixed` must diff/merge files that are nested multiple levels deep in a sparse directory. The use of pathspecs with `git reset --mixed` introduces scenarios in which internal contents of sparse directories may be matched by the pathspec. In order to reset *all* files in the repo that may match the pathspec, the following conditions on the pathspec require index expansion before performing the reset: * "magic" pathspecs * wildcard pathspecs that do not match only in-cone files or entire sparse directories * literal pathspecs matching something outside the sparse checkout definition Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-29reset: integrate with sparse indexLibravatar Victoria Dye1-3/+7
Disable `command_requires_full_index` repo setting and add `ensure_full_index` guards around code paths that cannot yet use sparse directory index entries. `reset --soft` does not modify the index, so no compatibility changes are needed for it to function without expanding the index. For all other reset modes (`--mixed`, `--hard`, `--keep`, `--merge`), the full index is expanded to prevent cache tree corruption and invalid variable accesses. Additionally, the `read_cache()` check verifying an uncorrupted index is moved after argument parsing and preparing the repo settings. The index is not used by the preceding argument handling, but `read_cache()` must be run *after* enabling sparse index for the command (so that the index is not expanded unnecessarily) and *before* using the index for reset (so that it is verified as uncorrupted). Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-22refs: drop force_create argument of create_reflog APILibravatar Han-Wen Nienhuys1-1/+1
There is only one caller, builtin/checkout.c, and it hardcodes force_create=1. This argument was introduced in abd0cd3a301 (refs: new public ref function: safe_create_reflog, 2015-07-21), which promised to immediately use it in a follow-on commit, but that never happened. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-21Merge branch 'ev/pull-already-up-to-date-is-noop'Libravatar Junio C Hamano1-2/+4
"git pull" with any strategy when the other side is behind us should succeed as it is a no-op, but doesn't. * ev/pull-already-up-to-date-is-noop: pull: should be noop when already-up-to-date
2021-11-19submodule: absorb git dir instead of dying on deinitLibravatar Mugdha Pattnaik1-10/+11
Currently, running 'git submodule deinit' on repos where the submodule's '.git' is a directory, aborts with a message that is not exactly user friendly. Let's change this to instead warn the user that the .git/ directory has been absorbed into the superproject. The rest of the deinit function can operate as it already does with new-style submodules. In one test, we used to require "git submodule deinit" to fail even with the "--force" option when the submodule's .git/ directory is not absorbed. Adjust it to expect the operation to pass. Suggested-by: Atharva Raykar <raykar.ath@gmail.com> Signed-off-by: Mugdha Pattnaik <mugdhapattnaik@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-19pull: don't say that merge is "the default strategy"Libravatar Alex Henrie1-1/+1
Git no longer has a default strategy for reconciling divergent branches, because there's no way for Git to know which strategy is appropriate in any particular situation. The initially proposed version in [*], that eventually became 031e2f7a (pull: abort by default when fast-forwarding is not possible, 2021-07-22), dropped this phrase from the message, but it was left in the final version by accident. * https://lore.kernel.org/git/20210627000855.530985-1-alexhenrie24@gmail.com/ Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18pull: should be noop when already-up-to-dateLibravatar Erwin Villejo1-2/+4
The already-up-to-date pull bug was fixed for --ff-only but it did not include the case where --ff or --ff-only are not specified. This updates the --ff-only fix to include the case where --ff or --ff-only are not specified in command line flags or config. Signed-off-by: Erwin Villejo <erwin.villejo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18checkout: fix "branch info" memory leaksLibravatar Ævar Arnfjörð Bjarmason1-31/+55
The "checkout" command is one of the main sources of leaks in the test suite, let's fix the common ones by not leaking from the "struct branch_info". Doing this is rather straightforward, albeit verbose, we need to xstrdup() constant strings going into the struct, and free() the ones we clobber as we go along. This also means that we can delete previous partial leak fixes in this area, i.e. the "path_to_free" accounting added by 96ec7b1e708 (Convert resolve_ref+xstrdup to new resolve_refdup function, 2011-12-13). There was some discussion about whether "we should retain the "const char *" here and cast at free() time, or have it be a "char *". Since this is not a public API with any sort of API boundary let's use "char *", as is already being done for the "refname" member of the same struct. The tests to mark as passing were found with: rm .prove; GIT_SKIP_TESTS=t0027 prove -j8 --state=save t[0-9]*.sh :: --immediate # apply & compile this change prove -j8 --state=failed :: --immediate I.e. the ones that were newly passing when the --state=failed command was run. I left out "t3040-subprojects-basic.sh" and "t4131-apply-fake-ancestor.sh" to to optimization-level related differences similar to the ones noted in[1], except that these would be something the current 'linux-leaks' job would run into. 1. https://lore.kernel.org/git/cover-v3-0.6-00000000000-20211022T175227Z-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-12Merge branch 'ab/fsck-unexpected-type'Libravatar Junio C Hamano1-1/+2
Regression fix. * ab/fsck-unexpected-type: object-file: free(*contents) only in read_loose_object() caller object-file: fix SEGV on free() regression in v2.34.0-rc2
2021-11-11object-file: free(*contents) only in read_loose_object() callerLibravatar Ævar Arnfjörð Bjarmason1-1/+2
In the preceding commit a free() of uninitialized memory regression in 96e41f58fe1 (fsck: report invalid object type-path combinations, 2021-10-01) was fixed, but we'd still have an issue with leaking memory from fsck_loose(). Let's fix that issue too. That issue was introduced in my 31deb28f5e0 (fsck: don't hard die on invalid object types, 2021-10-01). It can be reproduced under SANITIZE=leak with the test I added in 093fffdfbec (fsck tests: add test for fsck-ing an unknown type, 2021-10-01): ./t1450-fsck.sh --run=84 -vixd In some sense it's not a problem, we lost the same amount of memory in terms of things malloc'd and not free'd. It just moved from the "still reachable" to "definitely lost" column in valgrind(1) nomenclature[1], since we'd have die()'d before. But now that we don't hard die() anymore in the library let's properly free() it. Doing so makes this code much easier to follow, since we'll now have one function owning the freeing of the "contents" variable, not two. For context on that memory management pattern the read_loose_object() function was added in f6371f92104 (sha1_file: add read_loose_object() function, 2017-01-13) and subsequently used in c68b489e564 (fsck: parse loose object paths directly, 2017-01-13). The pattern of it being the task of both sides to free() the memory has been there in this form since its inception. 1. https://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10Merge branch 'ds/no-usable-cron-on-macos'Libravatar Junio C Hamano1-6/+21
"git maintenance run" learned to use system supplied scheduler backend, but cron on macOS turns out to be unusable for this purpose. * ds/no-usable-cron-on-macos: maintenance: disable cron on macOS
2021-11-10Merge branch 'jc/fix-pull-ff-only-when-already-up-to-date'Libravatar Junio C Hamano1-1/+28
"git pull --ff-only" and "git pull --rebase --ff-only" should make it a no-op to attempt pulling from a remote that is behind us, but instead the command errored out by saying it was impossible to fast-forward, which may technically be true, but not a useful thing to diagnose as an error. This has been corrected. * jc/fix-pull-ff-only-when-already-up-to-date: pull: --ff-only should make it a noop when already-up-to-date
2021-11-10maintenance: disable cron on macOSLibravatar Derrick Stolee1-6/+21
In eba1ba9 (maintenance: `git maintenance run` learned `--scheduler=<scheduler>`, 2021-09-04), we introduced the ability to specify a scheduler explicitly. This led to some extra checks around whether an alternative scheduler was available. This added the functionality of removing background maintenance from schedulers other than the one selected. On macOS, cron is technically available, but running 'crontab' triggers a UI prompt asking for special permissions. This is the major reason why launchctl is used as the default scheduler. The is_crontab_available() method triggers this UI prompt, causing user disruption. Remove this disruption by using an #ifdef to prevent running crontab this way on macOS. This has the unfortunate downside that if a user manually selects cron via the '--scheduler' option, then adjusting the scheduler later will not remove the schedule from cron. The '--scheduler' option ignores the is_available checks, which is how we can get into this situation. Extract the new check_crontab_process() method to avoid making the 'child' variable unused on macOS. The method is marked MAYBE_UNUSED because it has no callers on macOS. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-04Merge branch 'ar/fix-git-pull-no-verify'Libravatar Junio C Hamano1-0/+6
"git pull --no-verify" did not affect the underlying "git merge". * ar/fix-git-pull-no-verify: pull: honor --no-verify and do not call the commit-msg hook
2021-11-03Merge branch 'jx/message-fixes'Libravatar Junio C Hamano1-1/+1
Fixes to recently added messages. * jx/message-fixes: i18n: fix typos found during l10n for git 2.34.0
2021-11-03var: add GIT_DEFAULT_BRANCH variableLibravatar Thomas Weißschuh1-0/+7
Introduce the logical variable GIT_DEFAULT_BRANCH which represents the the default branch name that will be used by "git init". Currently this variable is equivalent to git config init.defaultbranch || 'master' This however will break if at one point the default branch is changed as indicated by `default_branch_name_advice` in `refs.c`. By providing this command ahead of time users of git can make their code forward-compatible. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-01Merge branch 'gc/use-repo-settings'Libravatar Junio C Hamano2-5/+5
It is wrong to read some settings directly from the config subsystem, as things like feature.experimental can affect their default values. * gc/use-repo-settings: gc: perform incremental repack when implictly enabled fsck: verify multi-pack-index when implictly enabled fsck: verify commit graph when implicitly enabled
2021-11-01Merge branch 'ab/ignore-replace-while-working-on-commit-graph'Libravatar Junio C Hamano1-1/+1
Teach "git commit-graph" command not to allow using replace objects at all, as we do not use the commit-graph at runtime when we see object replacement. * ab/ignore-replace-while-working-on-commit-graph: commit-graph: don't consider "replace" objects with "verify" commit-graph tests: fix another graph_git_two_modes() helper commit-graph tests: fix error-hiding graph_git_two_modes() helper
2021-10-31i18n: fix typos found during l10n for git 2.34.0Libravatar Jiang Xin1-1/+1
Emir and Jean-Noël reported typos in some i18n messages when preparing l10n for git 2.34.0. * Fix unstable spelling of config variable "gpg.ssh.defaultKeyCommand" which was introduced in commit fd9e226776 (ssh signing: retrieve a default key from ssh-agent, 2021-09-10). * Add missing space between "with" and "--python" which was introduced in commit bd0708c7eb (ref-filter: add %(raw) atom, 2021-07-26). * Fix unmatched single quote in 'builtin/index-pack.c' which was introduced in commit 8737dab346 (index-pack: refactor renaming in final(), 2021-09-09) [1] https://github.com/git-l10n/git-po/pull/567 Reported-by: Emir Sarı <bitigchi@me.com> Reported-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-29Merge branch 'ks/submodule-add-message-fix'Libravatar Junio C Hamano1-14/+22
Message regression fix. * ks/submodule-add-message-fix: submodule: drop unused sm_name parameter from append_fetch_remotes() submodule--helper: fix incorrect newlines in an error message
2021-10-29Merge branch 'ab/plug-random-leaks'Libravatar Junio C Hamano4-7/+14
Leakfix. * ab/plug-random-leaks: reflog: free() ref given to us by dwim_log() submodule--helper: fix small memory leaks clone: fix a memory leak of the "git_dir" variable grep: fix a "path_list" memory leak grep: use object_array_clear() in cmd_grep() grep: prefer "struct grep_opt" over its "void *" equivalent
2021-10-29Merge branch 'ab/ref-filter-leakfix'Libravatar Junio C Hamano3-16/+23
"git for-each-ref" family of commands were leaking the ref_sorting instances that hold sorting keys specified by the user; this has been corrected. * ab/ref-filter-leakfix: branch: use ref_sorting_release() ref-filter API user: add and use a ref_sorting_release() tag: use a "goto cleanup" pattern, leak less memory
2021-10-29Merge branch 'jk/http-push-status-fix'Libravatar Junio C Hamano1-0/+4
"git push" client talking to an HTTP server did not diagnose the lack of the final status report from the other side correctly, which has been corrected. * jk/http-push-status-fix: transport-helper: recognize "expecting report" error from send-pack send-pack: complain about "expecting report" with --helper-status
2021-10-29pull: --ff-only should make it a noop when already-up-to-dateLibravatar Junio C Hamano1-1/+28
Earlier, we made sure that "git pull --ff-only" (and "git -c pull.ff=only pull") errors out when our current HEAD is not an ancestor of the tip of the history we are merging, but the condition to trigger the error was implemented incorrectly. Imagine you forked from a remote branch, built your history on top of it, and then attempted to pull from them again. If they have not made any update in the meantime, our current HEAD is obviously not their ancestor, and this new error triggers. Without the --ff-only option, we just report that there is no need to pull; we did the same historically with --ff-only, too. Make sure we do not fail with the recently added check to restore the historical behaviour. Reported-by: Kenneth Arnold <ka37@calvin.edu> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28builtin/multi-pack-index.c: don't leak concatenated optionsLibravatar Taylor Blau1-0/+4
The `multi-pack-index` builtin dynamically allocates an array of command-line option for each of its separate modes by calling add_common_options() to concatante the common options with sub-command specific ones. Because this operation allocates a new array, we have to be careful to remember to free it. We already do this in the repack and write sub-commands, but verify and expire don't. Rectify this by calling FREE_AND_NULL as the other modes do. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28builtin/repack.c: avoid leaking child argumentsLibravatar Taylor Blau1-1/+3
`git repack` invokes a handful of child processes: one to write the actual pack, and optionally ones to repack promisor objects and update the MIDX. Most of these are freed automatically by calling `start_command()` (which invokes it on error) and `finish_command()` which calls it automatically. But repack_promisor_objects() can initialize a child_process, populate its array of arguments, and then return from the function before even calling start_command(). Make sure that the prepared list of arguments is freed by calling child_process_clear() ourselves to avoid leaking memory along this path. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28stash: get rid of unused argument in stash_staged()Libravatar Sergey Organov1-3/+3
Unused 'ps' argument was a left-over from original copy-paste of stash_patch(). Removed. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28doc: fix git credential synopsisLibravatar Jean-Noël Avila1-1/+1
The subcommand of git credential is not optional. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28pull: honor --no-verify and do not call the commit-msg hookLibravatar Alex Riesen1-0/+6
The option was incorrectly auto-translated to "--no-verify-signatures", which causes the unexpected effect of the hook being called. And an even more unexpected effect of disabling verification of signatures. The manual page describes the option to behave same as the similarly named option of "git merge", which seems to be the original intention of this option in the "pull" command. Signed-off-by: Alexander Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27builtin/pack-objects.c: don't leak memory via argumentsLibravatar Taylor Blau1-4/+7
When constructing arguments to pass to setup_revision(), pack-objects only frees the memory used by that array after calling get_object_list(). Ensure that we call strvec_clear() whether or not we use the arguments array by cleaning up whenever we exit the function (and rewriting one early return to jump to a label which frees the memory and then returns). We could avoid setting this array up altogether unless we are in the if-else block that calls get_object_list(), but setting up the argument array is intermingled with lots of other side-effects, e.g.: if (exclude_promisor_objects) { use_internal_rev_list = 1; fetch_if_missing = 0; strvec_push(&rp, "--exclude-promisor-objects"); } So it would be awkward to check exclude_promisor_objects twice: first to set use_internal_rev_list and fetch_if_missing, and then again above get_object_list() to push the relevant argument onto the array. Instead, leave the array's construction alone and make sure to free it unconditionally. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27reset: preserve skip-worktree bit in mixed resetLibravatar Victoria Dye1-0/+14
Change `update_index_from_diff` to set `skip-worktree` when applicable for new index entries. When `git reset --mixed <tree-ish>` is run, entries in the index with differences between the pre-reset HEAD and reset <tree-ish> are identified and handled with `update_index_from_diff`. For each file, a new cache entry in inserted into the index, created from the <tree-ish> side of the reset (without changing the working tree). However, the newly-created entry must have `skip-worktree` explicitly set in either of the following scenarios: 1. the file is in the current index and has `skip-worktree` set 2. the file is not in the current index but is outside of a defined sparse checkout definition Not setting the `skip-worktree` bit leads to likely-undesirable results for a user. It causes `skip-worktree` settings to disappear on the "diff"-containing files (but *only* the diff-containing files), leading to those files now showing modifications in `git status`. For example, when running `git reset --mixed` in a sparse checkout, some file entries outside of sparse checkout could show up as deleted, despite the user never deleting anything (and not wanting them on-disk anyway). Additionally, add a test to `t7102` to ensure `skip-worktree` is preserved in a basic `git reset --mixed` scenario and update a failure-documenting test from 19a0acc (t1092: test interesting sparse-checkout scenarios, 2021-01-23) with new expected behavior. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27submodule: drop unused sm_name parameter from append_fetch_remotes()Libravatar Jeff King1-3/+2
Commit c21fb4676f (submodule--helper: fix incorrect newlines in an error message, 2021-10-23) accidentally added a new, unused parameter while changing the name and signature of show_fetch_remotes() to append_fetch_remotes(). We can drop this to keep things simpler (and satisfy -Wunused-parameter). The error is likely because c21fb4676f is fixing a problem from 8c8195e9c3 (submodule--helper: introduce add-clone subcommand, 2021-07-10). An earlier iteration of that second commit introduced the same unused parameter (though it was dropped before it finally made it to 'next'), and the fix on top accidentally carried forward the extra parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-25Merge branch 'ab/pkt-line-cleanup'Libravatar Junio C Hamano1-2/+2
Code clean-up. * ab/pkt-line-cleanup: pkt-line.[ch]: remove unused packet_read_line_buf() pkt-line.[ch]: remove unused packet_buf_write_len()
2021-10-25Merge branch 'ab/mark-leak-free-tests-more'Libravatar Junio C Hamano2-8/+8
Bunch of tests are marked as "passing leak check". * ab/mark-leak-free-tests-more: merge: add missing strbuf_release() ls-files: add missing string_list_clear() ls-files: fix a trivial dir_clear() leak tests: fix test-oid-array leak, test in SANITIZE=leak tests: fix a memory leak in test-oidtree.c tests: fix a memory leak in test-parse-options.c tests: fix a memory leak in test-prio-queue.c
2021-10-25Merge branch 'ab/parse-options-cleanup'Libravatar Junio C Hamano3-2/+8
Random changes to parse-options implementation. * ab/parse-options-cleanup: parse-options: change OPT_{SHORT,UNSET} to an enum parse-options tests: test optname() output parse-options.[ch]: make opt{bug,name}() "static" commit-graph: stop using optname() parse-options.c: move optname() earlier in the file parse-options.h: make the "flags" in "struct option" an enum parse-options.c: use exhaustive "case" arms for "enum parse_opt_result" parse-options.[ch]: consistently use "enum parse_opt_result" parse-options.[ch]: consistently use "enum parse_opt_flags" parse-options.h: move PARSE_OPT_SHELL_EVAL between enums
2021-10-25Merge branch 'fs/ssh-signing'Libravatar Junio C Hamano1-0/+4
Use ssh public crypto for object and push-cert signing. * fs/ssh-signing: ssh signing: test that gpg fails for unknown keys ssh signing: tests for logs, tags & push certs ssh signing: duplicate t7510 tests for commits ssh signing: verify signatures using ssh-keygen ssh signing: provide a textual signing_key_id ssh signing: retrieve a default key from ssh-agent ssh signing: add ssh key format and signing code ssh signing: add test prereqs ssh signing: preliminary refactoring and clean-up
2021-10-25Merge branch 'ab/fsck-unexpected-type'Libravatar Junio C Hamano4-9/+42
"git fsck" has been taught to report mismatch between expected and actual types of an object better. * ab/fsck-unexpected-type: fsck: report invalid object type-path combinations fsck: don't hard die on invalid object types object-file.c: stop dying in parse_loose_header() object-file.c: return ULHR_TOO_LONG on "header too long" object-file.c: use "enum" return type for unpack_loose_header() object-file.c: simplify unpack_loose_short_header() object-file.c: make parse_loose_header_extended() public object-file.c: return -1, not "status" from unpack_loose_header() object-file.c: don't set "typep" when returning non-zero cat-file tests: test for current --allow-unknown-type behavior cat-file tests: add corrupt loose object test cat-file tests: test for missing/bogus object with -t, -s and -p cat-file tests: move bogus_* variable declarations earlier fsck tests: test for garbage appended to a loose object fsck tests: test current hash/type mismatch behavior fsck tests: refactor one test to use a sub-repo fsck tests: add test for fsck-ing an unknown type
2021-10-23submodule--helper: fix incorrect newlines in an error messageLibravatar Kaartic Sivaraam1-14/+23
A refactoring[1] done as part of the recent conversion of 'git submodule add' to builtin, changed the error message shown when a Git directory already exists locally for a submodule name. Before the refactoring, the error used to appear like so: --- START OF OUTPUT --- $ git submodule add ../sub/ subm A git directory for 'subm' is found locally with remote(s): origin /me/git-repos-for-test/sub If you want to reuse this local git directory instead of cloning again from /me/git-repos-for-test/sub use the '--force' option. If the local git directory is not the correct repo or you are unsure what this means choose another name with the '--name' option. --- END OF OUTPUT --- After the refactoring the error started appearing like so: --- START OF OUTPUT --- $ git submodule add ../sub/ subm A git directory for 'subm' is found locally with remote(s): origin /me/git-repos-for-test/sub fatal: If you want to reuse this local git directory instead of cloning again from /me/git-repos-for-test/sub use the '--force' option. If the local git directory is not the correct repo or if you are unsure what this means, choose another name with the '--name' option. --- END OF OUTPUT --- As one could observe the remote information is printed along with the first line rather than on its own line. Also, there's an additional newline following output. Make the error message consistent with the error message that used to be printed before the refactoring. This also moves the 'fatal:' prefix that appears in the middle of the error message to the first line as it would more appropriate to have it in the first line. The output after the change would look like: --- START OF OUTPUT --- $ git submodule add ../sub/ subm fatal: A git directory for 'subm' is found locally with remote(s): origin /me/git-repos-for-test/sub If you want to reuse this local git directory instead of cloning again from /me/git-repos-for-test/sub use the '--force' option. If the local git directory is not the correct repo or you are unsure what this means choose another name with the '--name' option. --- END OF OUTPUT --- [1]: https://lore.kernel.org/git/20210710074801.19917-5-raykar.ath@gmail.com/#t Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>