summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-12-13chainlint.sed: stop splitting "(..." into separate lines "(" and "..."Libravatar Eric Sunshine9-35/+37
Because `sed` is line-oriented, for ease of implementation, when chainlint.sed encounters an opening subshell in which the first command is cuddled with the "(", it splits the line into two lines: one containing only "(", and the other containing whatever follows "(". This allows chainlint.sed to get by with a single set of regular expressions for matching shell statements rather than having to duplicate each expression (one set for matching non-cuddled statements, and one set for matching cuddled statements). However, although syntactically and semantically immaterial, this transformation has no value to test authors and might even confuse them into thinking that the linter is misbehaving by inserting (whitespace) line-noise into the shell code it is validating. Moreover, it also allows an implementation detail of chainlint.sed to seep into the chainlint self-test "expect" files, which potentially makes it difficult to reuse the self-tests should a more capable chainlint ever be developed. To address these concerns, stop splitting cuddled "(..." into two lines. Note that, as an implementation artifact, due to sed's line-oriented nature, this change inserts a blank line at output time just before the "(..." line is emitted. It would be possible to suppress this blank line but doing so would add a fair bit of complexity to chainlint.sed. Therefore, rather than suppressing the extra blank line, the Makefile's `check-chainlint` target which runs the chainlint self-tests is instead modified to ignore blank lines when comparing chainlint output against the self-test "expect" output. This is a reasonable compromise for two reasons. First, the purpose of the chainlint self-tests is to verify that the ?!AMP?! annotations are being correctly added; precise whitespace is immaterial. Second, by necessity, chainlint.sed itself already throws away all blank lines within subshells since, when checking for a broken &&-chain, it needs to check the final _statement_ in a subshell, not the final _line_ (which might be blank), thus it has never made any attempt to precisely reproduce blank lines in its output. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13chainlint.sed: swallow comments consistentlyLibravatar Eric Sunshine6-4/+52
When checking for broken a &&-chain, chainlint.sed knows that the final statement in a subshell should not end with `&&`, so it takes care to make a distinction between the final line which is an actual statement and any lines which may be mere comments preceding the closing ')'. As such, it swallows comment lines so that they do not interfere with the &&-chain check. However, since `sed` does not provide any sort of real recursion, chainlint.sed only checks &&-chains in subshells one level deep; it doesn't do any checking in deeper subshells or in `{...}` blocks within subshells. Furthermore, on account of potential implementation complexity, it doesn't check &&-chains within `case` arms. Due to an oversight, it also doesn't swallow comments inside deep subshells, `{...}` blocks, or `case` statements, which makes its output inconsistent (swallowing comments in some cases but not others). Unfortunately, this inconsistency seeps into the chainlint self-test "expect" files, which potentially makes it difficult to reuse the self-tests should a more capable chainlint ever be developed. Therefore, teach chainlint.sed to consistently swallow comments in all cases. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13chainlint.sed: stop throwing away here-doc tagsLibravatar Eric Sunshine11-29/+35
The purpose of chainlint is to highlight problems it finds in test code by inserting annotations at the location of each problem. Arbitrarily eliding bits of the code it is checking is not helpful, yet this is exactly what chainlint.sed does by cavalierly and unnecessarily dropping the here-doc operator and tag; i.e. `cat <<TAG` becomes simply `cat` in the output. This behavior can make it more difficult for the test writer to align the annotated output of chainlint.sed with the original test code. Address this by retaining here-doc tags. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13chainlint.sed: don't mistake `<< word` in string as here-doc operatorLibravatar Eric Sunshine3-2/+36
Tighten here-doc recognition to prevent it from being fooled by text which looks like a here-doc operator but happens merely to be the content of a string, such as this real-world case from t7201: echo "<<<<<<< ours" && echo ourside && echo "=======" && echo theirside && echo ">>>>>>> theirs" This problem went unnoticed because chainlint.sed is not a real parser, but rather applies heuristics to pretend to understand shell code. In this case, it saw what it thought was a here-doc operator (`<< ours`), and fell off the end of the test looking for the closing tag "ours" which it never found, thus swallowed the remainder of the test without checking it for &&-chain breakage. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13chainlint.sed: make here-doc "<<-" operator recognition more POSIX-likeLibravatar Eric Sunshine1-4/+4
According to POSIX, "<<" and "<<-" are distinct shell operators. For the latter to be recognized, no whitespace is allowed before the "-", though whitespace is allowed after the operator. However, the chainlint patterns which identify here-docs are both too loose and too tight, incorrectly allowing whitespace between "<<" and "-" but disallowing it between "-" and the here-doc tag. Fix the patterns to better match POSIX. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13chainlint.sed: drop subshell-closing ">" annotationLibravatar Eric Sunshine39-89/+80
chainlint.sed inserts a ">" annotation at the beginning of a line to signal that its heuristics have identified an end-of-subshell. This was useful as a debugging aid during development of the script, but it has no value to test writers and might even confuse them into thinking that the linter is misbehaving by inserting line-noise into the shell code it is validating. Moreover, its presence also potentially makes it difficult to reuse the chainlint self-test "expect" output should a more capable linter ever be developed. Therefore, drop the ">" annotation. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13chainlint.sed: drop unnecessary distinction between ?!AMP?! and ?!SEMI?!Libravatar Eric Sunshine5-25/+24
>From inception, when chainlint.sed encountered a line using semicolon to separate commands rather than `&&`, it would insert a ?!SEMI?! annotation at the beginning of the line rather ?!AMP?! even though the &&-chain is also broken by the semicolon. Given a line such as: ?!SEMI?! cmd1; cmd2 && the ?!SEMI?! annotation makes it easier to see what the problem is than if the output had been: ?!AMP?! cmd1; cmd2 && which might confuse the test author into thinking that the linter is broken (since the line clearly ends with `&&`). However, now that the ?!AMP?! an ?!SEMI?! annotations are inserted at the point of breakage rather than at the beginning of the line, and taking into account that both represent a broken &&-chain, there is little reason to distinguish between the two. Using ?!AMP?! alone is sufficient to point the test author at the problem. For instance, in: cmd1; ?!AMP?! cmd2 && cmd3 it is clear that the &&-chain is broken between `cmd1` and `cmd2`. Likewise, in: cmd1 && cmd2 ?!AMP?! cmd3 it is clear that the &&-chain is broken between `cmd2` and `cmd3`. Finally, in: cmd1; ?!AMP?! cmd2 ?!AMP?! cmd3 it is clear that the &&-chain is broken between each command. Hence, there is no longer a good reason to make a distinction between a broken &&-chain due to a semicolon and a broken chain due to a missing `&&` at end-of-line. Therefore, drop the ?!SEMI?! annotation and use ?!AMP?! exclusively. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13chainlint.sed: tolerate harmless ";" at end of last line in blockLibravatar Eric Sunshine2-7/+8
chainlint.sed flags ";" when used as a command terminator since it breaks the &&-chain, thus can allow failures to go undetected. However, when a command terminated by ";" is the last command in the body of a compound statement, such as `command-2` in: if test $# -gt 1 then command-1 && command-2; fi then the ";" is harmless and the exit code from `command-2` is passed through untouched and becomes the exit code of the compound statement, as if the ";" was not present. Therefore, tolerate a trailing ";" in this position rather than complaining about broken &&-chain. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13chainlint.sed: improve ?!SEMI?! placement accuracyLibravatar Eric Sunshine5-18/+18
When chainlint.sed detects commands separated by a semicolon rather than by `&&`, it places a ?!SEMI?! annotation at the beginning of the line. However, this is an unusual location for programmers accustomed to error messages (from compilers, for instance) indicating the exact point of the problem. Therefore, relocate the ?!SEMI?! annotation to the location of the semicolon in order to better direct the programmer's attention to the source of the problem. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13chainlint.sed: improve ?!AMP?! placement accuracyLibravatar Eric Sunshine23-38/+38
When chainlint.sed detects a broken &&-chain, it places an ?!AMP?! annotation at the beginning of the line. However, this is an unusual location for programmers accustomed to error messages (from compilers, for instance) indicating the exact point of the problem. Therefore, relocate the ?!AMP?! annotation to the end of the line in order to better direct the programmer's attention to the source of the problem. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13t/Makefile: optimize chainlint self-testLibravatar Eric Sunshine1-6/+4
Rather than running `chainlint` and `diff` once per self-test -- which may become expensive as more tests are added -- instead run `chainlint` a single time over all tests bodies collectively and compare the result to the collective "expected" output. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13t/chainlint/one-liner: avoid overly intimate chainlint.sed knowledgeLibravatar Eric Sunshine2-2/+2
The purpose of chainlint.sed is to detect &&-chain breakage only within subshells (one level deep); it doesn't bother checking for top-level &&-chain breakage since the &&-chain checker built into t/test-lib.sh should detect broken &&-chains outside of subshells by making them magically exit with code 117. Unfortunately, one of the chainlint.sed self-tests has overly intimate knowledge of this particular division of responsibilities and only cares about what chainlint.sed itself will produce, while ignoring the fact that a more all-encompassing linter would complain about a broken &&-chain outside the subshell. This makes it difficult to re-use the test with a more capable chainlint implementation should one ever be developed. Therefore, adjust the test and its "expected" output to avoid being specific to the tunnel-vision of this one implementation. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13t/chainlint/*.test: generalize self-test commentaryLibravatar Eric Sunshine6-9/+6
The purpose of chainlint.sed is to detect &&-chain breakage only within subshells (one level deep); it doesn't bother checking for top-level &&-chain breakage since the &&-chain checker built into t/test-lib.sh should detect broken &&-chains outside of subshells by making them magically exit with code 117. However, this division of labor may not always be the case if a more capable chainlint implementation is ever developed. Beyond that, due to being sed-based and due to its use of heuristics, chainlint.sed has several limitations (such as being unable to detect &&-chain breakage in subshells more than one level deep since it only manually emulates recursion into a subshell). Some of the comments in the chainlint self-tests unnecessarily reflect the limitations of chainlint.sed even though those limitations are not what is being tested. Therefore, simplify and generalize the comments to explain only what is being tested, thus ensuring that they won't become outdated if a more capable chainlint is ever developed. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13t/chainlint/*.test: fix invalid test cases due to mixing quote typesLibravatar Eric Sunshine20-70/+38
The chainlint self-test code snippets are supposed to represent the body of a test_expect_success() or test_expect_failure(), yet the contents of a few tests would have caused the shell to report syntax errors had they been real test bodies due to the mix of single- and double-quotes. Although chainlint.sed, with its simplistic heuristics, is blind to this problem, a future more robust chainlint implementation might not have such a limitation. Therefore, stop mixing quote types haphazardly in those tests and unify quoting throughout. While at it, drop chunks of tests which merely repeat what is already tested elsewhere but with alternative quotes. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13t/chainlint/*.test: don't use invalid shell syntaxLibravatar Eric Sunshine3-4/+6
The chainlint self-test code snippets are supposed to represent the body of a test_expect_success() or test_expect_failure(), yet the contents of these tests would have caused the shell to report syntax errors had they been real test bodies. Although chainlint.sed, with its simplistic heuristics, is blind to these syntactic problems, a future more robust chainlint implementation might not have such a limitation, so make these snippets syntactically valid. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-10The second batchLibravatar Junio C Hamano1-0/+99
2021-12-10Merge branch 'en/rebase-x-fix'Libravatar Junio C Hamano2-2/+7
"git rebase -x" added an unnecessary 'exec' instructions before 'noop', which has been corrected. * en/rebase-x-fix: sequencer: avoid adding exec commands for non-commit creating commands
2021-12-10Merge branch 'cb/add-p-single-key-fix'Libravatar Junio C Hamano1-7/+9
The single-key-input mode in "git add -p" had some code to handle keys that generate a sequence of input via ReadKey(), which did not handle end-of-file correctly, which has been fixed. * cb/add-p-single-key-fix: add -p: avoid use of undefined $key when ReadKey -> EOF
2021-12-10Merge branch 'cb/mingw-gmtime-r'Libravatar Junio C Hamano2-1/+5
Build fix on Windows. * cb/mingw-gmtime-r: mingw: avoid fallback for {local,gm}time_r()
2021-12-10Merge branch 'yn/complete-date-format-options'Libravatar Junio C Hamano1-1/+1
The completion script (in contrib/) learns that the "--date" option of commands from the "git log" family takes "human" and "auto" as valid values. * yn/complete-date-format-options: completion: add human and auto: date format
2021-12-10Merge branch 'em/missing-pager'Libravatar Junio C Hamano2-1/+8
When a non-existent program is given as the pager, we tried to reuse an uninitialized child_process structure and crashed, which has been fixed. * em/missing-pager: pager: fix crash when pager program doesn't exist
2021-12-10Merge branch 'mp/absorb-submodule-git-dir-upon-deinit'Libravatar Junio C Hamano2-16/+16
"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 'bc/require-c99'Libravatar Junio C Hamano3-2/+15
Weather balloon to break people with compilers that do not support C99. * bc/require-c99: git-compat-util: add a test balloon for C99 support
2021-12-10Merge branch 'hn/create-reflog-simplify'Libravatar Junio C Hamano10-21/+16
A small simplification of API. * hn/create-reflog-simplify: refs: drop force_create argument of create_reflog API
2021-12-10Merge branch 'jt/midx-doc-fix'Libravatar Junio C Hamano1-5/+0
Docfix. * jt/midx-doc-fix: Doc: no midx and partial clone relation
2021-12-10Merge branch 'jk/t7006-sigpipe-tests-fix'Libravatar Junio C Hamano2-50/+23
The function to cull a child process and determine the exit status had two separate code paths for normal callers and callers in a signal handler, and the latter did not yield correct value when the child has caught a signal. The handling of the exit status has been unified for these two code paths. An existing test with flakiness has also been corrected. * jk/t7006-sigpipe-tests-fix: t7006: simplify exit-code checks for sigpipe tests t7006: clean up SIGPIPE handling in trace2 tests run-command: unify signal and regular logic for wait_or_whine()
2021-12-10Merge branch 'jk/refs-g11-workaround'Libravatar Junio C Hamano1-0/+7
Workaround for a false-alarm by gcc-11 * jk/refs-g11-workaround: refs: work around gcc-11 warning with REF_HAVE_NEW
2021-12-10Merge branch 'jk/fetch-pack-avoid-sigpipe-to-index-pack'Libravatar Junio C Hamano1-0/+5
"git fetch", when received a bad packfile, can fail with SIGPIPE. This wasn't wrong per-se, but we now detect the situation and fail in a more predictable way. * jk/fetch-pack-avoid-sigpipe-to-index-pack: fetch-pack: ignore SIGPIPE when writing to index-pack
2021-12-10Merge branch 'hk/ci-checkwhitespace-commentfix'Libravatar Junio C Hamano1-2/+3
Comment fix. * hk/ci-checkwhitespace-commentfix: ci(check-whitespace): update stale file top comments
2021-12-10Merge branch 'vd/sparse-reset'Libravatar Junio C Hamano8-37/+356
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 'tl/midx-docfix'Libravatar Junio C Hamano1-6/+6
Doc mark-up fix. * tl/midx-docfix: midx: fix a formatting issue in "multi-pack-index.txt"
2021-12-10Merge branch 'po/size-t-for-vs'Libravatar Junio C Hamano3-5/+5
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 'rs/mergesort'Libravatar Junio C Hamano1-1/+1
Bitop fix for platforms whose "long" is 32-bit. * rs/mergesort: mergesort: avoid left shift overflow
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 Hamano36-31/+98
Leakfix. * ab/checkout-branch-info-leakfix: checkout: fix "branch info" memory leaks
2021-12-10Merge branch 'jk/t5319-midx-corruption-test-deflake'Libravatar Junio C Hamano1-2/+4
Test fix. * jk/t5319-midx-corruption-test-deflake: t5319: corrupt more bytes of the midx checksum
2021-12-10Merge branch 'js/trace2-avoid-recursive-errors'Libravatar Junio C Hamano1-2/+7
trace2 error code path fix. * js/trace2-avoid-recursive-errors: trace2: disable tr2_dst before warning on write errors
2021-12-10Merge branch 'jt/pack-header-lshift-overflow'Libravatar Junio C Hamano1-1/+1
The code to decode the length of packed object size has been corrected. * jt/pack-header-lshift-overflow: packfile: avoid overflowing shift during decode
2021-12-10Merge branch 'jk/jump-merge-with-pathspec'Libravatar Junio C Hamano2-1/+4
The "merge" subcommand of "git jump" (in contrib/) silently ignored pathspec and other parameters. * jk/jump-merge-with-pathspec: git-jump: pass "merge" arguments to ls-files
2021-12-10Merge branch 'jk/test-bitmap-fix'Libravatar Junio C Hamano1-1/+1
Tighten code for testing pack-bitmap. * jk/test-bitmap-fix: test_bitmap_hashes(): handle repository without bitmaps
2021-12-10Merge branch 'ab/generate-command-list'Libravatar Junio C Hamano2-44/+56
Build optimization. * ab/generate-command-list: generate-cmdlist.sh: don't parse command-list.txt thrice generate-cmdlist.sh: replace "grep' invocation with a shell version generate-cmdlist.sh: do not shell out to "sed" generate-cmdlist.sh: stop sorting category lines generate-cmdlist.sh: replace for loop by printf's auto-repeat feature generate-cmdlist.sh: run "grep | sort", not "sort | grep" generate-cmdlist.sh: don't call get_categories() from category_list() generate-cmdlist.sh: spawn fewer processes generate-cmdlist.sh: trivial whitespace change command-list.txt: sort with "LC_ALL=C sort"
2021-12-10Merge branch 'tw/var-default-branch'Libravatar Junio C Hamano3-0/+30
"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 'jk/strbuf-addftime-seconds-since-epoch'Libravatar Junio C Hamano5-3/+20
The "--date=format:<strftime>" gained a workaround for the lack of system support for a non-local timezone to handle "%s" placeholder. * jk/strbuf-addftime-seconds-since-epoch: strbuf_addftime(): handle "%s" manually
2021-12-10Merge branch 'js/ci-no-directional-formatting'Libravatar Junio C Hamano2-0/+28
CI has been taught to catch some Unicode directional formatting sequence that can be used in certain mischief. * js/ci-no-directional-formatting: ci: disallow directional formatting
2021-12-10Merge branch 'jc/fix-first-object-walk'Libravatar Junio C Hamano1-5/+26
Doc update. * jc/fix-first-object-walk: docs: add headers in MyFirstObjectWalk docs: fix places that break compilation in MyFirstObjectWalk
2021-12-10Merge branch 'if/redact-packfile-uri'Libravatar Junio C Hamano6-5/+111
Redact the path part of packfile URI that appears in the trace output. * if/redact-packfile-uri: http-fetch: redact url on die() message fetch-pack: redact packfile urls in traces
2021-12-10Merge branch 'ja/doc-cleanup'Libravatar Junio C Hamano39-166/+168
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-10Merge branch 'gc/remote-with-fewer-static-global-variables'Libravatar Junio C Hamano5-113/+312
Code clean-up to eventually allow information on remotes defined for an arbitrary repository to be read. * gc/remote-with-fewer-static-global-variables: remote: die if branch is not found in repository remote: remove the_repository->remote_state from static methods remote: use remote_state parameter internally remote: move static variables into per-repository struct t5516: add test case for pushing remote refspecs
2021-12-10Merge branch 'vd/sparse-sparsity-fix-on-read'Libravatar Junio C Hamano5-17/+86
Ensure that the sparseness of the in-core index matches the index.sparse configuration specified by the repository immediately after the on-disk index file is read. * vd/sparse-sparsity-fix-on-read: sparse-index: update do_read_index to ensure correct sparsity sparse-index: add ensure_correct_sparsity function sparse-index: avoid unnecessary cache tree clearing test-read-cache.c: prepare_repo_settings after config init
2021-12-10Merge branch 'cw/protocol-v2-doc-fix'Libravatar Junio C Hamano1-3/+3
Doc update. * cw/protocol-v2-doc-fix: protocol-v2.txt: align delim-pkt spec with usage