path: root/t
AgeCommit message (Collapse)Author
15 hoursMerge branch 'ds/scalar-ignore-cron-error'Junio C Hamano
Allow "scalar" to warn but continue when its periodic maintenance feature cannot be enabled. * ds/scalar-ignore-cron-error: scalar: only warn when background maintenance fails t921*: test scalar behavior starting maintenance t: allow 'scalar' in test_must_fail
5 daysMerge branch 'en/rebase-incompatible-opts'Junio C Hamano
"git rebase" often ignored incompatible options instead of complaining, which has been corrected. * en/rebase-incompatible-opts: rebase: provide better error message for apply options vs. merge config rebase: put rebase_options initialization in single place rebase: fix formatting of rebase --reapply-cherry-picks option in docs rebase: clarify the OPT_CMDMODE incompatibilities rebase: add coverage of other incompatible options rebase: fix incompatiblity checks for --[no-]reapply-cherry-picks rebase: fix docs about incompatibilities with --root rebase: remove --allow-empty-message from incompatible opts rebase: flag --apply and --merge as incompatible rebase: mark --update-refs as requiring the merge backend
9 daysMerge branch 'tb/t0003-invoke-dd-more-portably'Junio C Hamano
Test portability fix. * tb/t0003-invoke-dd-more-portably: t0003: call dd with portable blocksize
9 daysMerge branch 'jk/hash-object-fsck'Junio C Hamano
"git hash-object" now checks that the resulting object is well formed with the same code as "git fsck". * jk/hash-object-fsck: fsck: do not assume NUL-termination of buffers hash-object: use fsck for object checks fsck: provide a function to fsck buffer without object struct t: use hash-object --literally when created malformed objects t7030: stop using invalid tag name t1006: stop using 0-padded timestamps t1007: modernize malformed object tests
9 daysMerge branch 'po/pretty-format-columns-doc'Junio C Hamano
Clarify column-padding operators in the pretty format string. * po/pretty-format-columns-doc: doc: pretty-formats note wide char limitations, and add tests doc: pretty-formats describe use of ellipsis in truncation doc: pretty-formats document negative column alignments doc: pretty-formats: delineate `%<|(` parameter values doc: pretty-formats: separate parameters from placeholders
12 daysscalar: only warn when background maintenance failsDerrick Stolee
A user reported issues with 'scalar clone' and 'scalar register' when working in an environment that had locked down the ability to run 'crontab' or 'systemctl' in that those commands registered as _failures_ instead of opportunistically reporting a success with just a warning about background maintenance. As a workaround, they can use GIT_TEST_MAINT_SCHEDULER to fake a successful background maintenance, but this is not a viable strategy for long-term. Update 'scalar register' and 'scalar clone' to no longer fail by modifying register_dir() to only warn when toggle_maintenance(1) fails. Since background maintenance is a "nice to have" and not a requirement for a working repository, it is best to move this from hard error to gentle warning. Signed-off-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
12 dayst921*: test scalar behavior starting maintenanceDerrick Stolee
A user recently reported issues with 'scalar register' and 'scalar clone' in that they failed when the system had permissions locked down so both 'crontab' and 'systemctl' commands failed when trying to enable background maintenance. This hard error is undesirable, but let's create tests that demonstrate this behavior before modiying the behavior. We can use GIT_TEST_MAINT_SCHEDULER to guarantee failure and check the exit code and error message. Signed-off-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
12 dayst: allow 'scalar' in test_must_failDerrick Stolee
This will enable scalar tests to use the test_must_fail helper, when necessary. Signed-off-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
13 daysMerge branch 'cw/fetch-remote-group-with-duplication'Junio C Hamano
"git fetch <group>", when "<group>" of remotes lists the same remote twice, unnecessarily failed when parallel fetching was enabled, which has been corrected. * cw/fetch-remote-group-with-duplication: fetch: fix duplicate remote parallel fetch bug
13 daysMerge branch 'km/send-email-with-v-reroll-count'Junio C Hamano
"git send-email -v 3" used to be expanded to "git send-email --validate 3" when the user meant to pass them down to "format-patch", which has been corrected. * km/send-email-with-v-reroll-count: send-email: relay '-v N' to format-patch
13 daysMerge branch 'cb/grep-pcre-ucp'Junio C Hamano
"grep -P" learned to use Unicode Character Property to grok character classes when processing \b and \w etc. * cb/grep-pcre-ucp: grep: correctly identify utf-8 characters with \{b,w} in -P
2023-01-25rebase: provide better error message for apply options vs. merge configElijah Newren
When config which selects the merge backend (currently, rebase.autosquash=true or rebase.updateRefs=true) conflicts with other options on the command line (such as --whitespace=fix), make the error message specifically call out the config option and specify how to override that config option on the command line. Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2023-01-25rebase: add coverage of other incompatible optionsElijah Newren
The git-rebase manual noted several sets of incompatible options, but we were missing tests for a few of these. Further, we were missing code checks for one of these, which could result in command line options being silently ignored. Also, note that adding a check for autosquash means that using --whitespace=fix together with the config setting rebase.autosquash=true will trigger an error. A subsequent commit will improve the error message. Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2023-01-25rebase: fix incompatiblity checks for --[no-]reapply-cherry-picksElijah Newren
--[no-]reapply-cherry-picks was traditionally only supported by the sequencer. Support was added for the apply backend, when --keep-base is also specified, in commit ce5238a690 ("rebase --keep-base: imply --reapply-cherry-picks", 2022-10-17). Make the code error out when --[no-]reapply-cherry-picks is specified AND the apply backend is used AND --keep-base is not specified. Also, clarify a number of comments surrounding the interaction of these flags. Helped-by: Phillip Wood <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2023-01-25rebase: fix docs about incompatibilities with --rootElijah Newren
In commit 5dacd4abdd ("git-rebase.txt: document incompatible options", 2018-06-25), I added notes about incompatibilities between options for the apply and merge backends. Unfortunately, I inverted the condition when --root was incompatible with the apply backend. Fix the documentation, and add a testcase that verifies the documentation matches the code. While at it, the documentation for --root also tried to cover some of the backend differences between the apply and merge backends in relation to reapplying cherry picks. The information: * assumed that the apply backend was the default (it isn't anymore) * was written before --reapply-cherry-picks became an option * was written before the detailed information on backend differences All of these factors make the sentence under --root about reapplying cherry picks contradict information that is now available elsewhere in the manual, and the other references are correct. So just strike this sentence. Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2023-01-25rebase: flag --apply and --merge as incompatibleElijah Newren
Previously, we flagged options which implied --apply as being incompatible with options which implied --merge. But if both options were given explicitly, then we didn't flag the incompatibility. The same is true with --apply and --interactive. Add the check, and add some testcases to verify these are also caught. Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2023-01-25rebase: mark --update-refs as requiring the merge backendElijah Newren
--update-refs is built in terms of the sequencer, which requires the merge backend. It was already marked as incompatible with the apply backend in the git-rebase manual, but the code didn't check for this incompatibility and warn the user. Check and error now. While at it, fix a typo in t3422...and fix some misleading wording (most options which used to be am-specific have since been implemented in the merge backend as well). Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2023-01-23Merge branch 'zh/scalar-progress'Junio C Hamano
"scalar" learned to give progress bar. * zh/scalar-progress: scalar: show progress if stderr refers to a terminal
2023-01-23Merge branch 'ds/omit-trailing-hash-in-index'Junio C Hamano
Quickfix for a topic already in 'master'. * ds/omit-trailing-hash-in-index: t1600: fix racy index.skipHash test
2023-01-23Merge branch 'ab/test-env-helper'Junio C Hamano
Remove "git env--helper" and demote it to a test-tool subcommand. * ab/test-env-helper: env-helper: move this built-in to "test-tool env-helper"
2023-01-23Merge branch 'kn/attr-from-tree'Junio C Hamano
"git check-attr" learned to take an optional tree-ish to read the .gitattributes file from. * kn/attr-from-tree: attr: add flag `--source` to work with tree-ish t0003: move setup for `--all` into new block
2023-01-23Merge branch 'rs/ls-tree-path-expansion-fix'Junio C Hamano
"git ls-tree --format='%(path) %(path)' $tree $path" showed the path three times, which has been corrected. * rs/ls-tree-path-expansion-fix: ls-tree: remove dead store and strbuf for quote_c_style() ls-tree: fix expansion of repeated %(path)
2023-01-23Merge branch 'en/t6426-todo-cleanup'Junio C Hamano
Test clean-up. * en/t6426-todo-cleanup: t6426: fix TODO about making test more comprehensive
2023-01-22t0003: call dd with portable blocksizeTorsten Bögershausen
The command `dd bs=101M count=1` is not portable, e.g. dd shipped with MacOs does not understand the 'M'. Use `dd bs=1048576 count=101`, which achives the same, instead. Signed-off-by: Torsten Bögershausen <> Signed-off-by: Junio C Hamano <>
2023-01-22Merge branch 'ab/bisect-cleanup'Junio C Hamano
Code clean-up. * ab/bisect-cleanup: bisect: no longer try to clean up left-over `.git/head-name` files bisect: remove Cogito-related code bisect run: fix the error message bisect: verify that a bogus option won't try to start a bisection bisect--helper: make the order consistently `argc, argv` bisect--helper: simplify exit code computation
2023-01-22Merge branch 'tl/ls-tree-code-clean-up'Junio C Hamano
Code clean-up. * tl/ls-tree-code-clean-up: t3104: remove shift code in 'test_ls_tree_format' ls-tree: cleanup the redundant SPACE ls-tree: make "line_termination" less generic ls-tree: fold "show_tree_data" into "cb" struct ls-tree: use a "struct options" ls-tree: don't use "show_tree_data" for "fast" callbacks
2023-01-22Merge branch 'ph/parse-date-reduced-precision'Junio C Hamano
Loosen date parsing heuristics. * ph/parse-date-reduced-precision: date.c: allow ISO 8601 reduced precision times
2023-01-22Merge branch 'jk/interop-error'Junio C Hamano
Test helper improvement. * jk/interop-error: t/interop: report which vanilla git command failed
2023-01-22Merge branch 'ar/test-cleanup'Junio C Hamano
Test clean-up. * ar/test-cleanup: t7527: use test_when_finished in 'case insensitive+preserving' t6422: drop commented out code t6003: uncomment test '--max-age=c3, --topo-order'
2023-01-22Merge branch 'jx/t1301-updates'Junio C Hamano
Test updates. * jx/t1301-updates: t1301: do not change $CWD in "shared=all" test case t1301: use test_when_finished for cleanup t1301: fix wrong template dir for git-init
2023-01-19fsck: do not assume NUL-termination of buffersJeff King
The fsck code operates on an object buffer represented as a pointer/len combination. However, the parsing of commits and tags is a little bit loose; we mostly scan left-to-right through the buffer, without checking whether we've gone past the length we were given. This has traditionally been OK because the buffers we feed to fsck always have an extra NUL after the end of the object content, which ends any left-to-right scan. That has always been true for objects we read from the odb, and we made it true for incoming index-pack/unpack-objects checks in a1e920a0a7 (index-pack: terminate object buffers with NUL, 2014-12-08). However, we recently added an exception: hash-object asks index_fd() to do fsck checks. That _may_ have an extra NUL (if we read from a pipe into a strbuf), but it might not (if we read the contents from the file). Nor can we just teach it to always add a NUL. We may mmap the on-disk file, which will not have any extra bytes (if it's a multiple of the page size). Not to mention that this is a rather subtle assumption for the fsck code to make. Instead, let's make sure that the fsck parsers don't ever look past the size of the buffer they've been given. This _almost_ works already, thanks to earlier work in 4d0d89755e (Make sure fsck_commit_buffer() does not run out of the buffer, 2014-09-11). The theory there is that we check up front whether we have the end of header double-newline separator. And then any left-to-right scanning we do is OK as long as it stops when it hits that boundary. However, we later softened that in 84d18c0bcf (fsck: it is OK for a tag and a commit to lack the body, 2015-06-28), which allows the double-newline header to be missing, but does require that the header ends in a newline. That was OK back then, because of the NUL-termination guarantees (including the one from a1e920a0a7 mentioned above). Because 84d18c0bcf guarantees that any header line does end in a newline, we are still OK with most of the left-to-right scanning. We only need to take care after completing a line, to check that there is another line (and we didn't run out of buffer). Most of these checks are just need to check "buffer < buffer_end" (where buffer is advanced as we parse) before scanning for the next header line. But here are a few notes: - we don't technically need to check for remaining buffer before parsing the very first line ("tree" for a commit, or "object" for a tag), because verify_headers() rejects a totally empty buffer. But we'll do so in the name of consistency and defensiveness. - there are some calls to strchr('\n'). These are actually OK by the "the final header line must end in a newline" guarantee from verify_headers(). They will always find that rather than run off the end of the buffer. Curiously, they do check for a NULL return and complain, but I believe that condition can never be reached. However, I converted them to use memchr() with a proper size and retained the NULL checks. Using memchr() is not much longer and makes it more obvious what is going on. Likewise, retaining the NULL checks serves as a defensive measure in case my analysis is wrong. - commit 9a1a3a4d4c (mktag: allow omitting the header/body \n separator, 2021-01-05), does check for the end-of-buffer condition, but does so with "!*buffer", relying explicitly on the NUL termination. We can accomplish the same thing with a pointer comparison. I also folded it into the follow-on conditional that checks the contents of the buffer, for consistency with the other checks. - fsck_ident() uses parse_timestamp(), which is based on strtoumax(). That function will happily skip past leading whitespace, including newlines, which makes it a risk. We can fix this by scanning to the first digit ourselves, and then using parse_timestamp() to do the actual numeric conversion. Note that as a side effect this fixes the fact that we missed zero-padded timestamps like "<email> 0123" (whereas we would complain about "<email> 0123"). I doubt anybody cares, but I mention it here for completeness. - fsck_tree() does not need any modifications. It relies on decode_tree_entry() to do the actual parsing, and that function checks both that there are enough bytes in the buffer to represent an entry, and that there is a NUL at the appropriate spot (one hash-length from the end; this may not be the NUL for the entry we are parsing, but we know that in the worst case, everything from our current position to that NUL is a filename, so we won't run out of bytes). In addition to fixing the code itself, we'd like to make sure our rather subtle assumptions are not violated in the future. So this patch does two more things: - add comments around verify_headers() documenting the link between what it checks and the memory safety of the callers. I don't expect this code to be modified frequently, but this may help somebody from accidentally breaking things. - add a thorough set of tests covering truncations at various key spots (e.g., for a "tree $oid" line, in the middle of the word "tree", right after it, after the space, in the middle of the $oid, and right at the end of the line. Most of these are fine already (it is only truncating right at the end of the line that is currently broken). And some of them are not even possible with the current code (we parse "tree " as a unit, so truncating before the space is equivalent). But I aimed here to consider the code a black box and look for any truncations that would be a problem for a left-to-right parser. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2023-01-19fetch: fix duplicate remote parallel fetch bugCalvin Wan
Fetching in parallel from a remote group with a duplicated remote results in the following: error: cannot lock ref '<ref>': is at <oid> but expected <oid> This doesn't happen in serial since fetching from the same remote that has already been fetched from is a noop. Therefore, remove any duplicated remotes after remote groups are parsed. Signed-off-by: Calvin Wan <> Signed-off-by: Junio C Hamano <>
2023-01-19doc: pretty-formats note wide char limitations, and add testsPhilip Oakley
The previous commits added clarifications to the column alignment placeholders, note that the spaces are optional around the parameters. Also, a proposed extension [1] to allow hard truncation (without ellipsis '..') highlighted that the existing code does not play well with wide characters, such as Asian fonts and emojis. For example, N wide characters take 2N columns so won't fit an odd number column width, causing misalignment somewhere. Further analysis also showed that decomposed characters, e.g. separate `a` + `umlaut` Unicode code-points may also be mis-counted, in some cases leaving multiple loose `umlauts` all combined together. Add some notes about these limitations, and add basic tests to demonstrate them. The chosen solution for the tests is to substitute any wide character that overlaps a splitting boundary for the unicode vertical ellipsis code point as a rare but 'obvious' substitution. An alternative could be the substitution with a single dot '.' which matches regular expression usage, and our two dot ellipsis, and further in scenarios where the bulk of the text is wide characters, would be obvious. In mainly 'ascii' scenarios a singleton emoji being substituted by a dot could be confusing. It is enough that the tests fail cleanly. The final choice for the substitute character can be deferred. [1] Signed-off-by: Philip Oakley <> Signed-off-by: Junio C Hamano <>
2023-01-18grep: correctly identify utf-8 characters with \{b,w} in -PCarlo Marcelo Arenas Belón
When UTF is enabled for a PCRE match, the corresponding flags are added to the pcre2_compile() call, but PCRE2_UCP wasn't included. This prevents extending the meaning of the character classes to include those new valid characters and therefore result in failed matches for expressions that rely on that extention, for ex: $ git grep -P '\bÆvar' Add PCRE2_UCP so that \w will include Æ and therefore \b could correctly match the beginning of that word. This has an impact on performance that has been estimated to be between 20% to 40% and that is shown through the added performance test. Signed-off-by: Carlo Marcelo Arenas Belón <> Acked-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2023-01-18hash-object: use fsck for object checksJeff King
Since c879daa237 (Make hash-object more robust against malformed objects, 2011-02-05), we've done some rudimentary checks against objects we're about to write by running them through our usual parsers for trees, commits, and tags. These parsers catch some problems, but they are not nearly as careful as the fsck functions (which make sense; the parsers are designed to be fast and forgiving, bailing only when the input is unintelligible). We are better off doing the more thorough fsck checks when writing objects. Doing so at write time is much better than writing garbage only to find out later (after building more history atop it!) that fsck complains about it, or hosts with transfer.fsckObjects reject it. This is obviously going to be a user-visible behavior change, and the test changes earlier in this series show the scope of the impact. But I'd argue that this is OK: - the documentation for hash-object is already vague about which checks we might do, saying that --literally will allow "any garbage[...] which might not otherwise pass standard object parsing or git-fsck checks". So we are already covered under the documented behavior. - users don't generally run hash-object anyway. There are a lot of spots in the tests that needed to be updated because creating garbage objects is something that Git's tests disproportionately do. - it's hard to imagine anyone thinking the new behavior is worse. Any object we reject would be a potential problem down the road for the user. And if they really want to create garbage, --literally is already the escape hatch they need. Note that the change here is actually in index_mem(), which handles the HASH_FORMAT_CHECK flag passed by hash-object. That flag is also used by "git-replace --edit" to sanity-check the result. Covering that with more thorough checks likewise seems like a good thing. Besides being more thorough, there are a few other bonuses: - we get rid of some questionable stack allocations of object structs. These don't seem to currently cause any problems in practice, but they subtly violate some of the assumptions made by the rest of the code (e.g., the "struct commit" we put on the stack and zero-initialize will not have a proper index from alloc_comit_index(). - likewise, those parsed object structs are the source of some small memory leaks - the resulting messages are much better. For example: [before] $ echo 'tree 123' | git hash-object -t commit --stdin error: bogus commit object 0000000000000000000000000000000000000000 fatal: corrupt commit [after] $ echo 'tree 123' | git.compile hash-object -t commit --stdin error: object fails fsck: badTreeSha1: invalid 'tree' line format - bad sha1 fatal: refusing to create malformed object Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2023-01-18t: use hash-object --literally when created malformed objectsJeff King
Many test scripts use hash-object to create malformed objects to see how we handle the results in various commands. In some cases we already have to use "hash-object --literally", because it does some rudimentary quality checks. But let's use "--literally" more consistently to future-proof these tests against hash-object learning to be more careful. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2023-01-18t7030: stop using invalid tag nameJeff King
We intentionally invalidate the signature of a tag by switching its tag name from "seventh" to "7th forged". However, the latter is not a valid tag name because it contains a space. This doesn't currently affect the test, but we're better off using something syntactically valid. That reduces the number of possible failure modes in the test, and future-proofs us if git hash-object gets more picky about its input. The t7031 script, which was mostly copied from t7030, has the same problem, so we'll fix it, too. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2023-01-18t1006: stop using 0-padded timestampsJeff King
The fake objects in t1006 use dummy timestamps like "0000000000 +0000". While this does make them look more like normal timestamps (which, unless it is 1970, have many digits), it actually violates our fsck checks, which complain about zero-padded timestamps. This doesn't currently break anything, but let's future-proof our tests against a version of hash-object which is a little more careful about its input. We don't actually care about the exact values here (and in fact, the helper functions in this script end up removing the timestamps anyway, so we don't even have to adjust other parts of the tests). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2023-01-18t1007: modernize malformed object testsJeff King
The tests in t1007 for detecting malformed objects have two anachronisms: - they use "sha1" instead of "oid" in variable names, even though the script as a whole has been adapted to handle sha256 - they use test_i18ngrep, which is no longer necessary Since we'll be adding a new similar test, let's clean these up so they are all consistently using the modern style. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2023-01-17t1600: fix racy index.skipHash testDerrick Stolee
The test 1600.6 can fail under --stress due to mtime collisions. Most of the tests include a removal of the index file to guarantee that the index is updated. However, the submodule test addded in ee1f0c242ef (read-cache: add index.skipHash config option, 2023-01-06) did not include this removal. Thus, on rare occasions, the test can fail because the index still has a non-null trailing hash, as detected by the helper added in da9acde14ed (test-lib-functions: add helper for trailing hash, 2023-01-06). By removing the submodule's index before the 'git -C sub add a' command, we guarantee that the index is rewritten with the new index.skipHash config option. Signed-off-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
2023-01-16Sync with 2.39.1Junio C Hamano
2023-01-16Merge branch 'ar/dup-words-fixes'Junio C Hamano
Typofixes. * ar/dup-words-fixes: *: fix typos which duplicate a word
2023-01-16Merge branch 'ds/omit-trailing-hash-in-index'Junio C Hamano
Introduce an optional configuration to allow the trailing hash that protects the index file from bit flipping. * ds/omit-trailing-hash-in-index: features: feature.manyFiles implies fast index writes test-lib-functions: add helper for trailing hash read-cache: add index.skipHash config option hashfile: allow skipping the hash function
2023-01-16Merge branch 'ws/single-file-cone'Junio C Hamano
The logic to see if we are using the "cone" mode by checking the sparsity patterns has been tightened to avoid mistaking a pattern that names a single file as specifying a cone. * ws/single-file-cone: dir: check for single file cone patterns
2023-01-16Merge branch 'jk/ext-diff-with-relative'Junio C Hamano
"git diff --relative" did not mix well with "git diff --ext-diff", which has been corrected. * jk/ext-diff-with-relative: diff: drop "name" parameter from prepare_temp_file() diff: clean up external-diff argv setup diff: use filespec path to set up tempfiles for ext-diff
2023-01-16Merge branch 'ds/bundle-uri-4'Junio C Hamano
Code clean-up. * ds/bundle-uri-4: test-bundle-uri: drop unused variables
2023-01-16Merge branch 'tr/am--no-verify'Junio C Hamano
Conditionally skip the pre-applypatch and applypatch-msg hooks when applying patches with 'git am'. * tr/am--no-verify: am: allow passing --no-verify flag
2023-01-16Merge branch 'es/t1509-root-fixes'Junio C Hamano
Test fixes. * es/t1509-root-fixes: t1509: facilitate repeated script invocations t1509: make "setup" test more robust t1509: fix failing "root work tree" test due to owner-check
2023-01-16scalar: show progress if stderr refers to a terminalZheNing Hu
Sometimes when users use scalar to download a monorepo with a long commit history, they want to check the progress bar to know how long they still need to wait during the fetch process, but scalar suppresses this output by default. So let's check whether scalar stderr refer to a terminal, if so, show progress, otherwise disable it. Signed-off-by: ZheNing Hu <> Acked-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
2023-01-15ls-tree: fix expansion of repeated %(path)René Scharfe
expand_show_tree() borrows the base strbuf given to us by read_tree() to build the full path of the current entry when handling %(path). Only its indirect caller, show_tree_fmt(), removes the added entry name. That works fine as long as %(path) is only included once in the format string, but accumulates duplicates if it's repeated: $ git ls-tree --format='%(path) %(path) %(path)' HEAD M* Makefile MakefileMakefile MakefileMakefileMakefile Reset the length after each use to get the same expansion every time; here's the behavior with this patch: $ ./git ls-tree --format='%(path) %(path) %(path)' HEAD M* Makefile Makefile Makefile Signed-off-by: René Scharfe <> Signed-off-by: Junio C Hamano <>