summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2021-06-10Merge branch 'ah/stash-usage-i18n-fix'Libravatar Junio C Hamano1-2/+2
i18n update. * ah/stash-usage-i18n-fix: stash: don't translate literal commands
2021-06-10Merge branch 'ah/merge-usage-i18n-fix'Libravatar Junio C Hamano1-2/+2
i18n update. * ah/merge-usage-i18n-fix: merge: don't translate literal commands
2021-06-02Merge branch 'ab/fsck-api-cleanup'Libravatar Junio C Hamano1-1/+2
Last minute compilation fix. * ab/fsck-api-cleanup: builtin/fsck.c: don't conflate "int" and "enum" in callback
2021-06-02builtin/fsck.c: don't conflate "int" and "enum" in callbackLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Fix a warning on AIX's xlc compiler that's been emitted since my a1aad71601a (fsck.h: use "enum object_type" instead of "int", 2021-03-28): "builtin/fsck.c", line 805.32: 1506-068 (W) Operation between types "int(*)(struct object*,enum object_type,void*,struct fsck_options*)" and "int(*)(struct object*,int,void*,struct fsck_options*)" is not allowed. I.e. it complains about us assigning a function with a prototype "int" where we're expecting "enum object_type". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-27Merge branch 'ab/pack-linkage-fix'Libravatar Junio C Hamano1-7/+167
"ld" on Solaris fails to link some test helpers, which has been worked around by reshuffling the inline function definitions from a header file to a source file that is the only user of them. * ab/pack-linkage-fix: pack-objects: move static inline from a header to the sole consumer
2021-05-27pack-objects: move static inline from a header to the sole consumerLibravatar Ævar Arnfjörð Bjarmason1-7/+167
Move the code that is only used in builtin/pack-objects.c out of pack-objects.h. This fixes an issue where Solaris's SunCC hasn't been able to compile git since 483fa7f42d9 (t/helper/test-bitmap.c: initial commit, 2021-03-31). The real origin of that issue is that in 898eba5e630 (pack-objects: refer to delta objects by index instead of pointer, 2018-04-14) utility functions only needed by builtin/pack-objects.c were added to pack-objects.h. Since then the header has been used in a few other places, but 483fa7f42d9 was the first time it was used by test helper. Since Solaris is stricter about linking and the oe_get_size_slow() function lives in builtin/pack-objects.c the build started failing with: Undefined first referenced symbol in file oe_get_size_slow t/helper/test-bitmap.o ld: fatal: symbol referencing errors. No output written to t/helper/test-tool On other platforms this is presumably OK because the compiler and/or linker detects that the "static inline" functions that reference oe_get_size_slow() aren't used. Let's solve this by moving the relevant code from pack-objects.h to builtin/pack-objects.c. This is almost entirely a code-only move, but because of the early macro definitions in that file referencing some of these inline functions we need to move the definition of "static struct packing_data to_pack" earlier, and declare these inline functions above the macros. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25Merge branch 'mt/init-template-userpath-fix'Libravatar Junio C Hamano1-1/+2
Regression fix. * mt/init-template-userpath-fix: init: fix bug regarding ~/ expansion in init.templateDir
2021-05-25init: fix bug regarding ~/ expansion in init.templateDirLibravatar Matheus Tavares1-1/+2
We used to read the init.templateDir setting at builtin/init-db.c using a git_config() callback that, in turn, called git_config_pathname(). To simplify the config reading logic at this file and plug a memory leak, this was replaced by a direct call to git_config_get_value() at e4de4502e6 ("init: remove git_init_db_config() while fixing leaks", 2021-03-14). However, this function doesn't provide path expanding semantics, like git_config_pathname() does, so paths with '~/' and '~user/' are treated literally. This makes 'git init' fail to handle init.templateDir paths using these constructs: $ git config init.templateDir '~/templates_dir' $ git init 'warning: templates not found in ~/templates_dir' Replace the git_config_get_value() call by git_config_get_pathname(), which does the '~/' and '~user/' expansions. Also add a regression test. Note that unlike git_config_get_value(), the config cache does not own the memory for the path returned by git_config_get_pathname(), so we must free() it. Reported on IRC by rkta. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-22Merge branch 'dl/stash-show-untracked-fixup'Libravatar Junio C Hamano1-4/+1
Another brown paper bag inconsistency fix for a new feature introduced during this cycle. * dl/stash-show-untracked-fixup: stash show: use stash.showIncludeUntracked even when diff options given
2021-05-22Merge branch 'wm/rev-parse-path-format-wo-arg'Libravatar Junio C Hamano1-0/+2
The "rev-parse" command did not diagnose the lack of argument to "--path-format" option, which was introduced in v2.31 era, which has been corrected. * wm/rev-parse-path-format-wo-arg: rev-parse: fix segfault with missing --path-format argument
2021-05-22stash show: use stash.showIncludeUntracked even when diff options givenLibravatar Denton Liu1-4/+1
If options pertaining to how the diff is displayed is provided to `git stash show`, the command will ignore the stash.showIncludeUntracked configuration variable, defaulting to not showing any untracked files. This is unintuitive behaviour since the format of the diff output and whether or not to display untracked files are orthogonal. Use stash.showIncludeUntracked even when diff options are given. Of course, this is still overridable via the command-line options. Update the documentation to explicitly say which configuration variables will be overridden when a diff options are given. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-20Merge branch 'en/dir-traversal'Libravatar Junio C Hamano3-6/+5
"git clean" and "git ls-files -i" had confusion around working on or showing ignored paths inside an ignored directory, which has been corrected. * en/dir-traversal: dir: introduce readdir_skip_dot_and_dotdot() helper dir: update stale description of treat_directory() dir: traverse into untracked directories if they may have ignored subfiles dir: avoid unnecessary traversal into ignored directory t3001, t7300: add testcase showcasing missed directory traversal t7300: add testcase showing unnecessary traversal into ignored directory ls-files: error out on -i unless -o or -c are specified dir: report number of visited directories and paths with trace2 dir: convert trace calls to trace2 equivalents
2021-05-17rev-parse: fix segfault with missing --path-format argumentLibravatar Wolfgang Müller1-0/+2
Calling "git rev-parse --path-format" without an argument segfaults instead of giving an error message. Commit fac60b8925 (rev-parse: add option for absolute or relative path formatting, 2020-12-13) added the argument parsing code but forgot to handle NULL. Returning an error makes sense here because there is no default value we could use. Add a test case to verify. Signed-off-by: Wolfgang Müller <wolf@oriole.systems> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-17stash: don't translate literal commandsLibravatar Alex Henrie1-2/+2
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-16Merge branch 'dl/stash-show-untracked-fixup'Libravatar Junio C Hamano1-2/+6
The code to handle options recently added to "git stash show" around untracked part of the stash segfaulted when these options were used on a stash entry that does not record untracked part. * dl/stash-show-untracked-fixup: stash show: fix segfault with --{include,only}-untracked t3905: correct test title
2021-05-16Merge branch 'lh/maintenance-leakfix'Libravatar Junio C Hamano1-2/+8
* lh/maintenance-leakfix: maintenance: fix two memory leaks
2021-05-16Merge branch 'dd/mailinfo-quoted-cr'Libravatar Junio C Hamano2-33/+133
"git mailinfo" (hence "git am") learned the "--quoted-cr" option to control how lines ending with CRLF wrapped in base64 or qp are handled. * dd/mailinfo-quoted-cr: am: learn to process quoted lines that ends with CRLF mailinfo: allow stripping quoted CR without warning mailinfo: allow squelching quoted CRLF warning mailinfo: warn if CRLF found in decoded base64/QP email mailinfo: stop parsing options manually mailinfo: load default metainfo_charset lazily
2021-05-16Merge branch 'mt/parallel-checkout-part-3'Libravatar Junio C Hamano4-15/+35
The final part of "parallel checkout". * mt/parallel-checkout-part-3: ci: run test round with parallel-checkout enabled parallel-checkout: add tests related to .gitattributes t0028: extract encoding helpers to lib-encoding.sh parallel-checkout: add tests related to path collisions parallel-checkout: add tests for basic operations checkout-index: add parallel checkout support builtin/checkout.c: complete parallel checkout support make_transient_cache_entry(): optionally alloc from mem_pool
2021-05-16Merge branch 'jt/push-negotiation'Libravatar Junio C Hamano1-1/+26
"git push" learns to discover common ancestor with the receiving end over protocol v2. * jt/push-negotiation: send-pack: support push negotiation fetch: teach independent negotiation (no packfile) fetch-pack: refactor command and capability write fetch-pack: refactor add_haves() fetch-pack: refactor process_acks()
2021-05-16merge: don't translate literal commandsLibravatar Alex Henrie1-2/+2
These strings have not been modified in any translation, nor should they be. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-14Merge branch 'mt/clean-clean'Libravatar Junio C Hamano1-3/+1
Code clean-up. * mt/clean-clean: clean: remove unnecessary variable
2021-05-14Merge branch 'ow/no-dryrun-in-add-i'Libravatar Junio C Hamano1-0/+2
"git add -i --dry-run" does not dry-run, which was surprising. The combination of options has taught to error out. * ow/no-dryrun-in-add-i: add: die if both --dry-run and --interactive are given
2021-05-13stash show: fix segfault with --{include,only}-untrackedLibravatar Denton Liu1-2/+6
When `git stash show --include-untracked` or `git stash show --only-untracked` is run on a stash that doesn't include an untracked entry, a segfault occurs. This happens because we do not check whether the untracked entry is actually present and just attempt to blindly dereference it. Ensure that the untracked entry is present before actually attempting to dereference it. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-13dir: introduce readdir_skip_dot_and_dotdot() helperLibravatar Elijah Newren2-6/+2
Many places in the code were doing while ((d = readdir(dir)) != NULL) { if (is_dot_or_dotdot(d->d_name)) continue; ...process d... } Introduce a readdir_skip_dot_and_dotdot() helper to make that a one-liner: while ((d = readdir_skip_dot_and_dotdot(dir)) != NULL) { ...process d... } This helper particularly simplifies checks for empty directories. Also use this helper in read_cached_dir() so that our statistics are consistent across platforms. (In other words, read_cached_dir() should have been using is_dot_or_dotdot() and skipping such entries, but did not and left it to treat_path() to detect and mark such entries as path_none.) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-13ls-files: error out on -i unless -o or -c are specifiedLibravatar Elijah Newren1-0/+3
ls-files --ignored can be used together with either --others or --cached. After being perplexed for a bit and digging in to the code, I assumed that ls-files -i was just broken and not printing anything and I had a nice patch ready to submit when I finally realized that -i can be used with --cached to find tracked ignores. While that was a mistake on my part, and a careful reading of the documentation could have made this more clear, I suspect this is an error others are likely to make as well. In fact, of two uses in our testsuite, I believe one of the two did make this error. In t1306.13, there are NO tracked files, and all the excludes built up and used in that test and in previous tests thus have to be about untracked files. However, since they were looking for an empty result, the mistake went unnoticed as their erroneous command also just happened to give an empty answer. -i will most the time be used with -o, which would suggest we could just make -i imply -o in the absence of either a -o or -c, but that would be a backward incompatible break. Instead, let's just flag -i without either a -o or -c as an error, and update the two relevant testcases to specify their intent. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-12maintenance: fix two memory leaksLibravatar Lénaïc Huard1-2/+8
Fixes two memory leaks when running `git maintenance start` or `git maintenance stop` in `update_background_schedule`: $ valgrind --leak-check=full ~/git/bin/git maintenance start ==76584== Memcheck, a memory error detector ==76584== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==76584== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==76584== Command: /home/lenaic/git/bin/git maintenance start ==76584== ==76584== ==76584== HEAP SUMMARY: ==76584== in use at exit: 34,880 bytes in 252 blocks ==76584== total heap usage: 820 allocs, 568 frees, 146,414 bytes allocated ==76584== ==76584== 65 bytes in 1 blocks are definitely lost in loss record 17 of 39 ==76584== at 0x483E6AF: malloc (vg_replace_malloc.c:306) ==76584== by 0x3DC39C: xrealloc (wrapper.c:126) ==76584== by 0x3992CC: strbuf_grow (strbuf.c:98) ==76584== by 0x39A473: strbuf_vaddf (strbuf.c:392) ==76584== by 0x39BC54: xstrvfmt (strbuf.c:979) ==76584== by 0x39BD2C: xstrfmt (strbuf.c:989) ==76584== by 0x18451B: update_background_schedule (gc.c:1977) ==76584== by 0x1846F6: maintenance_start (gc.c:2011) ==76584== by 0x1847B4: cmd_maintenance (gc.c:2030) ==76584== by 0x127A2E: run_builtin (git.c:453) ==76584== by 0x127E81: handle_builtin (git.c:704) ==76584== by 0x128142: run_argv (git.c:771) ==76584== ==76584== 240 bytes in 1 blocks are definitely lost in loss record 29 of 39 ==76584== at 0x4840D7B: realloc (vg_replace_malloc.c:834) ==76584== by 0x491CE5D: getdelim (in /usr/lib/libc-2.33.so) ==76584== by 0x39ADD7: strbuf_getwholeline (strbuf.c:635) ==76584== by 0x39AF31: strbuf_getdelim (strbuf.c:706) ==76584== by 0x39B064: strbuf_getline_lf (strbuf.c:727) ==76584== by 0x184273: crontab_update_schedule (gc.c:1919) ==76584== by 0x184678: update_background_schedule (gc.c:1997) ==76584== by 0x1846F6: maintenance_start (gc.c:2011) ==76584== by 0x1847B4: cmd_maintenance (gc.c:2030) ==76584== by 0x127A2E: run_builtin (git.c:453) ==76584== by 0x127E81: handle_builtin (git.c:704) ==76584== by 0x128142: run_argv (git.c:771) ==76584== ==76584== LEAK SUMMARY: ==76584== definitely lost: 305 bytes in 2 blocks ==76584== indirectly lost: 0 bytes in 0 blocks ==76584== possibly lost: 0 bytes in 0 blocks ==76584== still reachable: 34,575 bytes in 250 blocks ==76584== suppressed: 0 bytes in 0 blocks ==76584== Reachable blocks (those to which a pointer was found) are not shown. ==76584== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==76584== ==76584== For lists of detected and suppressed errors, rerun with: -s ==76584== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) Signed-off-by: Lénaïc Huard <lenaic@lhuard.fr> Acked-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11Merge branch 'jk/pack-objects-negative-options-fix'Libravatar Junio C Hamano1-0/+4
Options to "git pack-objects" that take numeric values like --window and --depth should not accept negative values; the input validation has been tightened. * jk/pack-objects-negative-options-fix: pack-objects: clamp negative depth to 0 t5316: check behavior of pack-objects --depth=0 pack-objects: clamp negative window size to 0 t5300: check that we produced expected number of deltas t5300: modernize basic tests
2021-05-11Merge branch 'js/merge-already-up-to-date-message-reword'Libravatar Junio C Hamano1-5/+9
A few variants of informational message "Already up-to-date" has been rephrased. * js/merge-already-up-to-date-message-reword: merge: fix swapped "up to date" message components merge(s): apply consistent punctuation to "up to date" messages
2021-05-11Merge branch 'rj/bisect-skip-honor-terms'Libravatar Junio C Hamano1-0/+1
"git bisect skip" when custom words are used for new/old did not work, which has been corrected. * rj/bisect-skip-honor-terms: bisect--helper: use BISECT_TERMS in 'bisect skip' command
2021-05-10Merge branch 'rs/repack-without-loosening-promised-objects'Libravatar Junio C Hamano2-3/+14
"git repack -A -d" in a partial clone unnecessarily loosened objects in promisor pack. * rs/repack-without-loosening-promised-objects: repack: avoid loosening promisor objects in partial clones
2021-05-10Merge branch 'bc/hash-transition-interop-part-1'Libravatar Junio C Hamano17-67/+71
SHA-256 transition. * bc/hash-transition-interop-part-1: hex: print objects using the hash algorithm member hex: default to the_hash_algo on zero algorithm value builtin/pack-objects: avoid using struct object_id for pack hash commit-graph: don't store file hashes as struct object_id builtin/show-index: set the algorithm for object IDs hash: provide per-algorithm null OIDs hash: set, copy, and use algo field in struct object_id builtin/pack-redundant: avoid casting buffers to struct object_id Use the final_oid_fn to finalize hashing of object IDs hash: add a function to finalize object IDs http-push: set algorithm when reading object ID Always use oidread to read into struct object_id hash: add an algo member to struct object_id
2021-05-10am: learn to process quoted lines that ends with CRLFLibravatar Đoàn Trần Công Danh1-0/+51
In previous changes, mailinfo has learnt to process lines that decoded from base64 or quoted-printable, and ends with CRLF. Let's teach "am" that new trick, too. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10mailinfo: allow squelching quoted CRLF warningLibravatar Đoàn Trần Công Danh1-0/+12
In previous change, Git starts to warn for quoted CRLF in decoded base64/QP email. Despite those warnings are usually helpful, quoted CRLF could be part of some users' workflow. Let's give them an option to turn off the warning completely. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-07Merge branch 'ah/plugleaks'Libravatar Junio C Hamano7-4/+15
Plug various leans reported by LSAN. * ah/plugleaks: builtin/rm: avoid leaking pathspec and seen builtin/rebase: release git_format_patch_opt too builtin/for-each-ref: free filter and UNLEAK sorting. mailinfo: also free strbuf lists when clearing mailinfo builtin/checkout: clear pending objects after diffing builtin/check-ignore: clear_pathspec before returning builtin/bugreport: don't leak prefixed filename branch: FREE_AND_NULL instead of NULL'ing real_ref bloom: clear each bloom_key after use ls-files: free max_prefix when done wt-status: fix multiple small leaks revision: free remainder of old commit list in limit_list
2021-05-07Merge branch 'ps/rev-list-object-type-filter'Libravatar Junio C Hamano2-10/+28
"git rev-list" learns the "--filter=object:type=<type>" option, which can be used to exclude objects of the given kind from the packfile generated by pack-objects. * ps/rev-list-object-type-filter: rev-list: allow filtering of provided items pack-bitmap: implement combined filter pack-bitmap: implement object type filter list-objects: implement object type filter list-objects: support filtering by tag and commit list-objects: move tag processing into its own function revision: mark commit parents as NOT_USER_GIVEN uploadpack.txt: document implication of `uploadpackfilter.allow`
2021-05-07Merge branch 'mt/add-rm-in-sparse-checkout'Libravatar Junio C Hamano3-26/+89
"git add" and "git rm" learned not to touch those paths that are outside of sparse checkout. * mt/add-rm-in-sparse-checkout: rm: honor sparse checkout patterns add: warn when asked to update SKIP_WORKTREE entries refresh_index(): add flag to ignore SKIP_WORKTREE entries pathspec: allow to ignore SKIP_WORKTREE entries on index matching add: make --chmod and --renormalize honor sparse checkouts t3705: add tests for `git add` in sparse checkouts add: include magic part of pathspec on --refresh error
2021-05-07Merge branch 'ps/config-global-override'Libravatar Junio C Hamano1-3/+3
Replace GIT_CONFIG_NOSYSTEM mechanism to decline from reading the system-wide configuration file with GIT_CONFIG_SYSTEM that lets users specify from which file to read the system-wide configuration (setting it to an empty file would essentially be the same as setting NOSYSTEM), and introduce GIT_CONFIG_GLOBAL to override the per-user configuration in $HOME/.gitconfig. * ps/config-global-override: t1300: fix unset of GIT_CONFIG_NOSYSTEM leaking into subsequent tests config: allow overriding of global and system configuration config: unify code paths to get global config paths config: rename `git_etc_config()`
2021-05-07Merge branch 'zh/format-ref-array-optim'Libravatar Junio C Hamano3-8/+32
"git (branch|tag) --format=..." has been micro-optimized. * zh/format-ref-array-optim: ref-filter: reuse output buffer ref-filter: get rid of show_ref_array_item
2021-05-07clean: remove unnecessary variableLibravatar Matheus Tavares1-3/+1
The variable `matches` used to hold the return of a `dir_path_match()` call that was removed in 95c11ecc73 ("Fix error-prone fill_directory() API; make it only return matches", 2020-04-01). Now `matches` will always hold 0, which is the value it's initialized with; and the condition `matches != MATCHED_EXACTLY` will always evaluate to true. So let's remove this unnecessary variable. Interestingly, it seems that `matches != MATCHED_EXACTLY` was already unnecessary before 95c11ecc73. That's because `remove_directories` is always set to 1 when we have pathspecs; So, in the condition `!remove_directories && matches != MATCHED_EXACTLY`, we would either: - have pathspecs (or have been given `-d`) and ignore `matches` because `remove_directories` is 1; or - not have pathspecs (nor `-d`) and end up just checking that `0 != MATCHED_EXACTLY`, as `matches` would never get reassigned after its zero initialization (because there is no pathspec to match). Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-07mailinfo: stop parsing options manuallyLibravatar Đoàn Trần Công Danh1-30/+45
In a later change, mailinfo will learn more options, let's switch to our robust parse_options framework before that step. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-07mailinfo: load default metainfo_charset lazilyLibravatar Đoàn Trần Công Danh1-9/+31
In a later change, we will use parse_option to parse mailinfo's options. In mailinfo, both "-u", "-n", and "--encoding" try to set the same field, with "-u" reset that field to some default value from configuration variable "i18n.commitEncoding". Let's delay the setting of that field until we finish processing all options. By doing that, "i18n.commitEncoding" can be parsed on demand. More importantly, it cleans the way for using parse_option. This change introduces some inconsistent brackets "{}" in "if/else if" construct, however, we will rewrite them in the next few changes. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-07add: die if both --dry-run and --interactive are givenLibravatar Øystein Walle1-0/+2
The interactive machinery does not obey --dry-run. Die appropriately if both flags are passed. Signed-off-by: Øystein Walle <oystwa@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-05checkout-index: add parallel checkout supportLibravatar Matheus Tavares1-9/+15
Allow checkout-index to use the parallel checkout framework, honoring the checkout.workers configuration. There are two code paths in checkout-index which call `checkout_entry()`, and thus, can make use of parallel checkout: `checkout_file()`, which is used to write paths explicitly given at the command line; and `checkout_all()`, which is used to write all paths in the index, when the `--all` option is given. In both operation modes, checkout-index doesn't abort immediately on a `checkout_entry()` failure. Instead, it tries to check out all remaining paths before exiting with a non-zero exit code. To keep this behavior when parallel checkout is being used, we must allow `run_parallel_checkout()` to try writing the queued entries before we exit, even if we already got an error code from a previous `checkout_entry()` call. However, `checkout_all()` doesn't return on errors, it calls `exit()` with code 128. We could make it call `run_parallel_checkout()` before exiting, but it makes the code easier to follow if we unify the exit path for both checkout-index modes at `cmd_checkout_index()`, and let this function take care of the interactions with the parallel checkout API. So let's do that. With this change, we also have to consider whether we want to keep using 128 as the error code for `git checkout-index --all`, while we use 1 for `git checkout-index <path>` (even when the actual error is the same). Since there is not much value in having code 128 only for `--all`, and there is no mention about it in the docs (so it's unlikely that changing it will break any existing script), let's make both modes exit with code 1 on `checkout_entry()` errors. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-05builtin/checkout.c: complete parallel checkout supportLibravatar Matheus Tavares1-4/+17
Pathspec-limited checkouts (like `git checkout *.txt`) are performed by a code path that doesn't yet support parallel checkout because it calls checkout_entry() directly, instead of unpack_trees(). Let's add parallel checkout support for this code path too. The transient cache entries allocated in checkout_merged() are now allocated in a mem_pool which is only discarded after parallel checkout finishes. This is done because the entries need to be valid when run_parallel_checkout() is called. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-05make_transient_cache_entry(): optionally alloc from mem_poolLibravatar Matheus Tavares3-3/+3
Allow make_transient_cache_entry() to optionally receive a mem_pool struct in which it should allocate the entry. This will be used in the following patch, to store some transient entries which should persist until parallel checkout finishes. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-05fetch: teach independent negotiation (no packfile)Libravatar Jonathan Tan1-1/+26
Currently, the packfile negotiation step within a Git fetch cannot be done independent of sending the packfile, even though there is at least one application wherein this is useful. Therefore, make it possible for this negotiation step to be done independently. A subsequent commit will use this for one such application - push negotiation. This feature is for protocol v2 only. (An implementation for protocol v0 would require a separate implementation in the fetch, transport, and transport helper code.) In the protocol, the main hindrance towards independent negotiation is that the server can unilaterally decide to send the packfile. This is solved by a "wait-for-done" argument: the server will then wait for the client to say "done". In practice, the client will never say it; instead it will cease requests once it is satisfied. In the client, the main change lies in the transport and transport helper code. fetch_refs_via_pack() performs everything needed - protocol version and capability checks, and the negotiation itself. There are 2 code paths that do not go through fetch_refs_via_pack() that needed to be individually excluded: the bundle transport (excluded through requiring smart_options, which the bundle transport doesn't support) and transport helpers that do not support takeover. If or when we support independent negotiation for protocol v0, we will need to modify these 2 code paths to support it. But for now, report failure if independent negotiation is requested in these cases. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-03pack-objects: clamp negative depth to 0Libravatar Jeff King1-0/+2
A negative delta depth makes no sense, and the code is not prepared to handle it. If passed "--depth=-1" on the command line, then this line from break_delta_chains(): cur->depth = (total_depth--) % (depth + 1); triggers a divide-by-zero. This is undefined behavior according to the C standard, but on POSIX systems results in SIGFPE killing the process. This is certainly one way to inform the use that the command was invalid, but it's a bit friendlier to just treat it as "don't allow any deltas", which we already do for --depth=0. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-03pack-objects: clamp negative window size to 0Libravatar Jeff King1-0/+2
A negative window size makes no sense, and the code in find_deltas() is not prepared to handle it. If you pass "-1", for example, we end up generate a 0-length array of "struct unpacked", but our loop assumes it has at least one entry in it (and we end up reading garbage memory). We could complain to the user about this, but it's more forgiving to just clamp it to 0, which means "do not find any deltas at all". The 0-case is already tested earlier in the script, so we'll make sure this does the same thing. Reported-by: Yiyuan guo <yguoaz@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-03merge: fix swapped "up to date" message componentsLibravatar Josh Soref1-5/+9
The rewrite of git-merge from shell to C in 1c7b76be7d (Build in merge, 2008-07-07) accidentally transformed the message: Already up-to-date. (nothing to squash) to: (nothing to squash)Already up-to-date. due to reversed printf() arguments. This problem has gone unnoticed despite being touched over the years by 7f87aff22c (Teach/Fix pull/fetch -q/-v options, 2008-11-15) and bacec47845 (i18n: git-merge basic messages, 2011-02-22), and tangentially by bef4830e88 (i18n: merge: mark messages for translation, 2016-06-17) and 7560f547e6 (treewide: correct several "up-to-date" to "up to date", 2017-08-23). Fix it by restoring the message to its intended order. While at it, help translators out by avoiding "sentence Lego". [es: rewrote commit message] Co-authored-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-03merge(s): apply consistent punctuation to "up to date" messagesLibravatar Eric Sunshine1-1/+1
Although the various "Already up to date" messages resulting from merge attempts share identical phrasing, they use a mix of punctuation ranging from "." to "!" and even "Yeeah!", which leads to extra work for translators. Ease the job of translators by settling upon "." as punctuation for all such messages. While at it, take advantage of printf_ln() to further ease the translation task so translators need not worry about line termination, and fix a case of missing line termination in the (unused) merge_ort_nonrecursive() function. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>