* What's cooking in git.git (Oct 2023, #06; Fri, 13)
From: Junio C Hamano @ 2023-10-14 20:12 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive. A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).
There are too many topics marked with "Needs review" label. I can
help reviewing some of them myself, but obviously it will not scale.
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[Graduated to 'master']
* ar/diff-index-merge-base-fix (2023-10-02) 1 commit
(merged to 'next' on 2023-10-06 at 0ff4dfc0e1)
+ diff: fix --merge-base with annotated tags
"git diff --merge-base X other args..." insisted that X must be a
commit and errored out when given an annotated tag that peels to a
commit, but we only need it to be a committish. This has been
corrected.
source: <20231001151845.3621551-1-hi@alyssa.is>
* ds/mailmap-entry-update (2023-10-12) 1 commit
(merged to 'next' on 2023-10-12 at 3de300ac62)
+ mailmap: change primary address for Derrick Stolee
Update mailmap entry for Derrick.
Will merge to 'master' immediately.
source: <pull.1592.git.1697131834003.gitgitgadget@gmail.com>
* jk/commit-graph-leak-fixes (2023-10-03) 10 commits
(merged to 'next' on 2023-10-06 at 5d202ef8b9)
+ commit-graph: clear oidset after finishing write
+ commit-graph: free write-context base_graph_name during cleanup
+ commit-graph: free write-context entries before overwriting
+ commit-graph: free graph struct that was not added to chain
+ commit-graph: delay base_graph assignment in add_graph_to_chain()
+ commit-graph: free all elements of graph chain
+ commit-graph: move slab-clearing to close_commit_graph()
+ merge: free result of repo_get_merge_bases()
+ commit-reach: free temporary list in get_octopus_merge_bases()
+ t6700: mark test as leak-free
Leakfix.
source: <20231003202504.GA7697@coredump.intra.peff.net>
* jk/decoration-and-other-leak-fixes (2023-10-05) 3 commits
(merged to 'next' on 2023-10-06 at 5fc05c94dc)
+ daemon: free listen_addr before returning
+ revision: clear decoration structs during release_revisions()
+ decorate: add clear_decoration() function
Leakfix.
source: <20231005212802.GA982892@coredump.intra.peff.net>
* js/submodule-fix-misuse-of-path-and-name (2023-10-03) 6 commits
(merged to 'next' on 2023-10-06 at 1054b6e752)
+ t7420: test that we correctly handle renamed submodules
+ t7419: test that we correctly handle renamed submodules
+ t7419, t7420: use test_cmp_config instead of grepping .gitmodules
+ t7419: actually test the branch switching
+ submodule--helper: return error from set-url when modifying failed
+ submodule--helper: use submodule_from_path in set-{url,branch}
In .gitmodules files, submodules are keyed by their names, and the
path to the submodule whose name is $name is specified by the
submodule.$name.path variable. There were a few codepaths that
mixed the name and path up when consulting the submodule database,
which have been corrected. It took long for these bugs to be found
as the name of a submodule initially is the same as its path, and
the problem does not surface until it is moved to a different path,
which apparently happens very rarely.
source: <0a0a157f88321d25fdb0be771a454b3410a449f3.camel@archlinux.org>
* la/trailer-test-and-doc-updates (2023-09-07) 13 commits
(merged to 'next' on 2023-10-06 at 69fef35819)
+ trailer doc: <token> is a <key> or <keyAlias>, not both
+ trailer doc: separator within key suppresses default separator
+ trailer doc: emphasize the effect of configuration variables
+ trailer --unfold help: prefer "reformat" over "join"
+ trailer --parse docs: add explanation for its usefulness
+ trailer --only-input: prefer "configuration variables" over "rules"
+ trailer --parse help: expose aliased options
+ trailer --no-divider help: describe usual "---" meaning
+ trailer: trailer location is a place, not an action
+ trailer doc: narrow down scope of --where and related flags
+ trailer: add tests to check defaulting behavior with --no-* flags
+ trailer test description: this tests --where=after, not --where=before
+ trailer tests: make test cases self-contained
Test coverage for trailers has been improved.
source: <pull.1564.v3.git.1694125209.gitgitgadget@gmail.com>
--------------------------------------------------
[New Topics]
* tb/format-pack-doc-update (2023-10-12) 2 commits
- Documentation/gitformat-pack.txt: fix incorrect MIDX documentation
- Documentation/gitformat-pack.txt: fix typo
Doc update.
Expecting a reroll.
cf. <xmqq5y3b4id2.fsf@gitster.g>
source: <cover.1697144959.git.me@ttaylorr.com>
* ps/do-not-trust-commit-graph-blindly-for-existence (2023-10-13) 1 commit
- commit: detect commits that exist in commit-graph but not in the ODB
(this branch is used by kn/rev-list-missing-fix.)
The codepath to traverse the commit-graph learned to notice that a
commit is missing (e.g., corrupt repository lost an object), even
though it knows something about the commit (like its parents) from
what is in commit-graph.
Comments?
source: <b0bf576c51a706367a758b8e30eca37edb9c2734.1697200576.git.ps@pks.im>
* tb/pair-chunk-expect-size (2023-10-13) 8 commits
- midx: read `OOFF` chunk with `pair_chunk_expect()`
- midx: read `OIDL` chunk with `pair_chunk_expect()`
- midx: read `OIDF` chunk with `pair_chunk_expect()`
- commit-graph: read `BIDX` chunk with `pair_chunk_expect()`
- commit-graph: read `GDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `CDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `OIDF` chunk with `pair_chunk_expect()`
- chunk-format: introduce `pair_chunk_expect()` helper
(this branch uses jk/chunk-bounds.)
Code clean-up for jk/chunk-bounds topic.
Comments?
source: <45cac29403e63483951f7766c6da3c022c68d9f0.1697225110.git.me@ttaylorr.com>
source: <cover.1697225110.git.me@ttaylorr.com>
--------------------------------------------------
[Stalled]
* pw/rebase-sigint (2023-09-07) 1 commit
- rebase -i: ignore signals when forking subprocesses
If the commit log editor or other external programs (spawned via
"exec" insn in the todo list) receive internactive signal during
"git rebase -i", it caused not just the spawned program but the
"Git" process that spawned them, which is often not what the end
user intended. "git" learned to ignore SIGINT and SIGQUIT while
waiting for these subprocesses.
Expecting a reroll.
cf. <12c956ea-330d-4441-937f-7885ab519e26@gmail.com>
source: <pull.1581.git.1694080982621.gitgitgadget@gmail.com>
* tk/cherry-pick-sequence-requires-clean-worktree (2023-06-01) 1 commit
- cherry-pick: refuse cherry-pick sequence if index is dirty
"git cherry-pick A" that replays a single commit stopped before
clobbering local modification, but "git cherry-pick A..B" did not,
which has been corrected.
Expecting a reroll.
cf. <999f12b2-38d6-f446-e763-4985116ad37d@gmail.com>
source: <pull.1535.v2.git.1685264889088.gitgitgadget@gmail.com>
* jc/diff-cached-fsmonitor-fix (2023-09-15) 3 commits
- diff-lib: fix check_removed() when fsmonitor is active
- Merge branch 'jc/fake-lstat' into jc/diff-cached-fsmonitor-fix
- Merge branch 'js/diff-cached-fsmonitor-fix' into jc/diff-cached-fsmonitor-fix
(this branch uses jc/fake-lstat.)
The optimization based on fsmonitor in the "diff --cached"
codepath is resurrected with the "fake-lstat" introduced earlier.
It is unknown if the optimization is worth resurrecting, but in case...
source: <xmqqr0n0h0tw.fsf@gitster.g>
--------------------------------------------------
[Cooking]
* jc/fail-stash-to-store-non-stash (2023-10-11) 1 commit
- stash: be careful what we store
Feeding "git stash store" with a random commit that was not created
by "git stash create" now errors out.
Will merge to 'next'?
source: <xmqqbkd4lwj0.fsf_-_@gitster.g>
* jc/doc-unit-tests-fixup (2023-10-11) 1 commit
- SQUASH???
(this branch uses js/doc-unit-tests and js/doc-unit-tests-with-cmake.)
Quick fix for jc/doc-unit-tests topic to unbreak CI running on 'seen'.
source: <xmqqwmvskf8t.fsf@gitster.g>
* bc/racy-4gb-files (2023-10-13) 2 commits
- Prevent git from rehashing 4GiB files
- t: add a test helper to truncate files
The index file has room only for lower 32-bit of the file size in
the cached stat information, which means cached stat information
will have 0 in its sd_size member for a file whose size is multiple
of 4GiB. This is mistaken for a racily clean path. Avoid it by
storing a bogus sd_size value instead for such files.
Will merge to 'next'?
source: <20231012160930.330618-1-sandals@crustytoothpaste.net>
* jc/grep-f-relative-to-cwd (2023-10-12) 1 commit
- grep: -f <path> is relative to $cwd
"cd sub && git grep -f patterns" tried to read "patterns" file at
the top level of the working tree; it has been corrected to read
"sub/patterns" instead.
Needs review.
source: <xmqqedhzg37z.fsf@gitster.g>
* tb/path-filter-fix (2023-10-10) 17 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: drop unnecessary `graph_read_bloom_data_context`
- commit-graph.c: unconditionally load Bloom filters
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- commit-graph: new filter ver. that fixes murmur3
- repo-settings: introduce commitgraph.changedPathsVersion
- t4216: test changed path filters with high bit paths
- t/helper/test-read-graph: implement `bloom-filters` mode
- bloom.h: make `load_bloom_filter_from_graph()` public
- t/helper/test-read-graph.c: extract `dump_graph_info()`
- gitformat-commit-graph: describe version 2 of BDAT
- commit-graph: ensure Bloom filters are read with consistent settings
- revision.c: consult Bloom filters for root commits
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
The Bloom filter used for path limited history traversal was broken
on systems whose "char" is unsigned; update the implementation and
bump the format version to 2.
Needs (hopefully final and quick) review.
source: <cover.1696969994.git.me@ttaylorr.com>
* ak/pretty-decorate-more-fix (2023-10-09) 1 commit
(merged to 'next' on 2023-10-12 at 3cbb4c2268)
+ pretty: fix ref filtering for %(decorate) formats
Unlike "git log --pretty=%D", "git log --pretty="%(decorate)" did
not auto-initialize the decoration subsystem, which has been
corrected.
Will merge to 'master'.
source: <20231008202307.1568477-1-andy.koppe@gmail.com>
* en/docfixes (2023-10-09) 25 commits
- documentation: add missing parenthesis
- documentation: add missing quotes
- documentation: add missing fullstops
- documentation: add some commas where they are helpful
- documentation: fix whitespace issues
- documentation: fix capitalization
- documentation: fix punctuation
- documentation: use clearer prepositions
- documentation: add missing hyphens
- documentation: remove unnecessary hyphens
- documentation: add missing article
- documentation: fix choice of article
- documentation: whitespace is already generally plural
- documentation: fix singular vs. plural
- documentation: fix verb vs. noun
- documentation: fix adjective vs. noun
- documentation: fix verb tense
- documentation: employ consistent verb tense for a list
- documentation: fix subject/verb agreement
- documentation: remove extraneous words
- documentation: add missing words
- documentation: fix apostrophe usage
- documentation: fix typos
- documentation: fix small error
- documentation: wording improvements
Documentation typo and grammo fixes.
Needs review.
source: <pull.1595.git.1696747527.gitgitgadget@gmail.com>
* kn/rev-list-missing-fix (2023-10-13) 4 commits
- rev-list: add commit object support in `--missing` option
- rev-list: move `show_commit()` to the bottom
- revision: rename bit to `do_not_die_on_missing_objects`
- Merge branch 'ps/do-not-trust-commit-graph-blindly-for-existence' into kn/rev-list-missing-fix
(this branch uses ps/do-not-trust-commit-graph-blindly-for-existence.)
"git rev-list --missing" did not work for missing commit objects,
which has been corrected.
Needs review.
source: <20231009105528.17777-1-karthik.188@gmail.com>
* sn/cat-file-doc-update (2023-10-09) 1 commit
(merged to 'next' on 2023-10-10 at 6719ba7bd4)
+ doc/cat-file: make synopsis and description less confusing
"git cat-file" documentation updates.
Will merge to 'master'.
source: <20231009175604.2361700-1-stepnem@smrk.net>
* xz/commit-title-soft-limit-doc (2023-10-09) 1 commit
(merged to 'next' on 2023-10-10 at 0bf3d9ed51)
+ doc: correct the 50 characters soft limit (+)
Doc update.
Will merge to 'master'.
source: <pull.1585.v2.git.git.1696778367151.gitgitgadget@gmail.com>
* jk/chunk-bounds (2023-10-09) 20 commits
(merged to 'next' on 2023-10-10 at 21139603ce)
+ chunk-format: drop pair_chunk_unsafe()
+ commit-graph: detect out-of-order BIDX offsets
+ commit-graph: check bounds when accessing BIDX chunk
+ commit-graph: check bounds when accessing BDAT chunk
+ commit-graph: bounds-check generation overflow chunk
+ commit-graph: check size of generations chunk
+ commit-graph: bounds-check base graphs chunk
+ commit-graph: detect out-of-bounds extra-edges pointers
+ commit-graph: check size of commit data chunk
+ midx: check size of revindex chunk
+ midx: bounds-check large offset chunk
+ midx: check size of object offset chunk
+ midx: enforce chunk alignment on reading
+ midx: check size of pack names chunk
+ commit-graph: check consistency of fanout table
+ midx: check size of oid lookup chunk
+ commit-graph: check size of oid fanout chunk
+ midx: stop ignoring malformed oid fanout chunk
+ t: add library for munging chunk-format files
+ chunk-format: note that pair_chunk() is unsafe
(this branch is used by tb/pair-chunk-expect-size.)
The codepaths that read "chunk" formatted files have been corrected
to pay attention to the chunk size and notice broken files.
Will merge to 'master'.
source: <20231009205544.GA3281950@coredump.intra.peff.net>
* ps/rewritten-is-per-worktree-doc (2023-10-10) 1 commit
(merged to 'next' on 2023-10-12 at 501b960e8c)
+ doc/git-worktree: mention "refs/rewritten" as per-worktree refs
Doc update.
Will merge to 'master'.
source: <985ac850eb6e60ae76601acc8bfbcd56f99348b4.1696935657.git.ps@pks.im>
* jc/merge-ort-attr-index-fix (2023-10-09) 1 commit
(merged to 'next' on 2023-10-10 at b139b87502)
+ merge-ort: initialize repo in index state
Fix "git merge-tree" to stop segfaulting when the --attr-source
option is used.
Will merge to 'master'.
source: <pull.1583.v3.git.git.1696857660374.gitgitgadget@gmail.com>
* sn/typo-grammo-phraso-fixes (2023-10-05) 5 commits
- t/README: fix multi-prerequisite example
- doc/gitk: s/sticked/stuck/
- git-jump: admit to passing merge mode args to ls-files
- doc/diff-options: improve wording of the log.diffMerges mention
- doc: fix some typos, grammar and wording issues
Many typos, ungrammatical sentences and wrong phrasing have been
fixed.
Needs review.
source: <20231003082107.3002173-1-stepnem@smrk.net>
* so/diff-merges-dd (2023-10-09) 3 commits
- completion: complete '--dd'
- diff-merges: introduce '--dd' option
- diff-merges: improve --diff-merges documentation
"git log" and friends learned "--dd" that is a short-hand for
"--diff-merges=first-parent -p".
Will merge to 'next'?
source: <20231009160535.236523-1-sorganov@gmail.com>
* vd/loose-ref-iteration-optimization (2023-10-09) 4 commits
(merged to 'next' on 2023-10-12 at 99e2f83855)
+ files-backend.c: avoid stat in 'loose_fill_ref_dir'
+ dir.[ch]: add 'follow_symlink' arg to 'get_dtype'
+ dir.[ch]: expose 'get_dtype'
+ ref-cache.c: fix prefix matching in ref iteration
The code to iterate over loose references have been optimized to
reduce the number of lstat() system calls.
Will merge to 'master'.
source: <pull.1594.v2.git.1696888736.gitgitgadget@gmail.com>
* jc/update-list-references-to-lore (2023-10-06) 1 commit
- doc: update list archive reference to use lore.kernel.org
Doc update.
Needs review.
source: <xmqq7cnz741s.fsf@gitster.g>
* cc/git-replay (2023-10-10) 14 commits
- replay: stop assuming replayed branches do not diverge
- replay: add --contained to rebase contained branches
- replay: add --advance or 'cherry-pick' mode
- replay: use standard revision ranges
- replay: make it a minimal server side command
- replay: remove HEAD related sanity check
- replay: remove progress and info output
- replay: add an important FIXME comment about gpg signing
- replay: change rev walking options
- replay: introduce pick_regular_commit()
- replay: die() instead of failing assert()
- replay: start using parse_options API
- replay: introduce new builtin
- t6429: remove switching aspects of fast-rebase
Introduce "git replay", a tool meant on the server side without
working tree to recreate a history.
Needs (hopefully final and quick) review.
source: <20231010123847.2777056-1-christian.couder@gmail.com>
* tb/repack-max-cruft-size (2023-10-09) 5 commits
(merged to 'next' on 2023-10-09 at 38f039e880)
+ repack: free existing_cruft array after use
(merged to 'next' on 2023-10-06 at b3ca6df3b9)
+ builtin/repack.c: avoid making cruft packs preferred
+ builtin/repack.c: implement support for `--max-cruft-size`
+ builtin/repack.c: parse `--max-pack-size` with OPT_MAGNITUDE
+ t7700: split cruft-related tests to t7704
"git repack" learned "--max-cruft-size" to prevent cruft packs from
growing without bounds.
Will merge to 'master'.
source: <cover.1696293862.git.me@ttaylorr.com>
source: <20231007172031.GA1524950@coredump.intra.peff.net>
source: <035393935108d02aaf8927189b05102f4f74f340.1696370003.git.me@ttaylorr.com>
* ak/color-decorate-symbols (2023-10-03) 1 commit
- decorate: add color.decorate.symbols config option
A new config for coloring.
Needs review.
source: <20231003205442.22963-1-andy.koppe@gmail.com>
* jc/attr-tree-config (2023-10-13) 2 commits
- attr: add attr.tree for setting the treeish to read attributes from
- attr: read attributes from HEAD when bare repo
The attribute subsystem learned to honor `attr.tree` configuration
that specifies which tree to read the .gitattributes files from.
Will merge to 'next'?
source: <pull.1577.v5.git.git.1697218770.gitgitgadget@gmail.com>
* js/update-urls-in-doc-and-comment (2023-09-26) 4 commits
- doc: refer to internet archive
- doc: update links for andre-simon.de
- doc: update links to current pages
- doc: switch links to https
Stale URLs have been updated to their current counterparts (or
archive.org) and HTTP links are replaced with working HTTPS links.
Needs review.
source: <pull.1589.v2.git.1695553041.gitgitgadget@gmail.com>
* la/trailer-cleanups (2023-09-26) 4 commits
- trailer: only use trailer_block_* variables if trailers were found
- trailer: use offsets for trailer_start/trailer_end
- trailer: find the end of the log message
- commit: ignore_non_trailer computes number of bytes to ignore
Code clean-up.
Needs review.
source: <pull.1563.v4.git.1695709372.gitgitgadget@gmail.com>
* eb/hash-transition (2023-10-02) 30 commits
- t1016-compatObjectFormat: add tests to verify the conversion between objects
- t1006: test oid compatibility with cat-file
- t1006: rename sha1 to oid
- test-lib: compute the compatibility hash so tests may use it
- builtin/ls-tree: let the oid determine the output algorithm
- object-file: handle compat objects in check_object_signature
- tree-walk: init_tree_desc take an oid to get the hash algorithm
- builtin/cat-file: let the oid determine the output algorithm
- rev-parse: add an --output-object-format parameter
- repository: implement extensions.compatObjectFormat
- object-file: update object_info_extended to reencode objects
- object-file-convert: convert commits that embed signed tags
- object-file-convert: convert commit objects when writing
- object-file-convert: don't leak when converting tag objects
- object-file-convert: convert tag objects when writing
- object-file-convert: add a function to convert trees between algorithms
- object: factor out parse_mode out of fast-import and tree-walk into in object.h
- cache: add a function to read an OID of a specific algorithm
- tag: sign both hashes
- commit: export add_header_signature to support handling signatures on tags
- commit: convert mergetag before computing the signature of a commit
- commit: write commits for both hashes
- object-file: add a compat_oid_in parameter to write_object_file_flags
- object-file: update the loose object map when writing loose objects
- loose: compatibilty short name support
- loose: add a mapping between SHA-1 and SHA-256 for loose objects
- repository: add a compatibility hash algorithm
- object-names: support input of oids in any supported hash
- oid-array: teach oid-array to handle multiple kinds of oids
- object-file-convert: stubs for converting from one object format to another
Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.
Needs review.
source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>
* jx/remote-archive-over-smart-http (2023-10-04) 4 commits
- archive: support remote archive from stateless transport
- transport-helper: call do_take_over() in connect_helper
- transport-helper: call do_take_over() in process_connect
- transport-helper: no connection restriction in connect_helper
"git archive --remote=<remote>" learned to talk over the smart
http (aka stateless) transport.
Needs review.
source: <cover.1696432593.git.zhiyou.jx@alibaba-inc.com>
* jx/sideband-chomp-newline-fix (2023-10-04) 3 commits
- pkt-line: do not chomp newlines for sideband messages
- pkt-line: memorize sideband fragment in reader
- test-pkt-line: add option parser for unpack-sideband
Sideband demultiplexer fixes.
Needs review.
source: <cover.1696425168.git.zhiyou.jx@alibaba-inc.com>
* ty/merge-tree-strategy-options (2023-10-11) 2 commits
(merged to 'next' on 2023-10-12 at 9b873601df)
+ merge: introduce {copy|clear}_merge_options()
(merged to 'next' on 2023-09-29 at aa65b54416)
+ merge-tree: add -X strategy option
"git merge-tree" learned to take strategy backend specific options
via the "-X" option, like "git merge" does.
Will merge to 'master'.
source: <pull.1565.v6.git.1695522222723.gitgitgadget@gmail.com>
* js/config-parse (2023-09-21) 5 commits
- config-parse: split library out of config.[c|h]
- config.c: accept config_parse_options in git_config_from_stdin
- config: report config parse errors using cb
- config: split do_event() into start and flush operations
- config: split out config_parse_options
The parsing routines for the configuration files have been split
into a separate file.
Needs review.
source: <cover.1695330852.git.steadmon@google.com>
* jc/fake-lstat (2023-09-15) 1 commit
- cache: add fake_lstat()
(this branch is used by jc/diff-cached-fsmonitor-fix.)
A new helper to let us pretend that we called lstat() when we know
our cache_entry is up-to-date via fsmonitor.
Needs review.
source: <xmqqcyykig1l.fsf@gitster.g>
* rs/parse-options-value-int (2023-09-18) 2 commits
- parse-options: use and require int pointer for OPT_CMDMODE
- parse-options: add int value pointer to struct option
A bit of type safety for the "value" pointer used in the
parse-options API.
Not ready yet.
cf. <4014e490-c6c1-453d-b0ed-645220e3e614@web.de>
source: <e6d8a291-03de-cfd3-3813-747fc2cad145@web.de>
* js/doc-unit-tests (2023-10-09) 3 commits
- ci: run unit tests in CI
- unit tests: add TAP unit test framework
- unit tests: add a project plan document
(this branch is used by jc/doc-unit-tests-fixup and js/doc-unit-tests-with-cmake.)
Process to add some form of low-level unit tests has started.
Expecting a reroll to address CI breakage.
source: <cover.1696889529.git.steadmon@google.com>
* js/doc-unit-tests-with-cmake (2023-10-09) 7 commits
- cmake: handle also unit tests
- cmake: use test names instead of full paths
- cmake: fix typo in variable name
- artifacts-tar: when including `.dll` files, don't forget the unit-tests
- unit-tests: do show relative file paths
- unit-tests: do not mistake `.pdb` files for being executable
- cmake: also build unit tests
(this branch is used by jc/doc-unit-tests-fixup; uses js/doc-unit-tests.)
Update the base topic to work with CMake builds.
Needs review.
source: <pull.1579.v3.git.1695640836.gitgitgadget@gmail.com>
* jc/rerere-cleanup (2023-08-25) 4 commits
- rerere: modernize use of empty strbuf
- rerere: try_merge() should use LL_MERGE_ERROR when it means an error
- rerere: fix comment on handle_file() helper
- rerere: simplify check_one_conflict() helper function
Code clean-up.
Not ready to be reviewed yet.
source: <20230824205456.1231371-1-gitster@pobox.com>
* rj/status-bisect-while-rebase (2023-08-01) 1 commit
- status: fix branch shown when not only bisecting
"git status" is taught to show both the branch being bisected and
being rebased when both are in effect at the same time.
Needs review.
cf. <xmqqtttia3vn.fsf@gitster.g>
source: <48745298-f12b-8efb-4e48-90d2c22a8349@gmail.com>
--------------------------------------------------
[Discarded]
* tb/ci-coverity (2023-09-21) 1 commit
. .github/workflows: add coverity action
GitHub CI workflow has learned to trigger Coverity check.
Superseded by the js/ci-coverity topic.
source: <b23951c569660e1891a7fb3ad2c2ea1952897bd7.1695332105.git.me@ttaylorr.com>
* cw/git-std-lib (2023-09-11) 7 commits
. SQUASH???
. git-std-lib: add test file to call git-std-lib.a functions
. git-std-lib: introduce git standard library
. parse: create new library for parsing strings and env values
. config: correct bad boolean env value error message
. wrapper: remove dependency to Git-specific internal file
. hex-ll: split out functionality from hex
Another libification effort.
Superseded by the cw/prelim-cleanup topic.
cf. <xmqqy1hfrk6p.fsf@gitster.g>
cf. <20230915183927.1597414-1-jonathantanmy@google.com>
source: <20230908174134.1026823-1-calvinwan@google.com>
* so/diff-merges-d (2023-09-11) 2 commits
- diff-merges: introduce '-d' option
- diff-merges: improve --diff-merges documentation
Superseded by the so/diff-merges-dd topic.
source: <20230909125446.142715-1-sorganov@gmail.com>
* kn/rev-list-ignore-missing-links (2023-09-20) 1 commit
. revision: add `--ignore-missing-links` user option
Surface the .ignore_missing_links bit that stops the revision
traversal from stopping and dying when encountering a missing
object to a new command line option of "git rev-list", so that the
objects that are required but are missing can be enumerated.
Superseded by kn/rev-list-missing-fix
source: <20230920104507.21664-1-karthik.188@gmail.com>
^ permalink raw reply
* Re: [PATCH 21/20] t5319: make corrupted large-offset test more robust
From: Junio C Hamano @ 2023-10-14 19:42 UTC (permalink / raw)
To: Jeff King; +Cc: git, Taylor Blau
In-Reply-To: <20231014004348.GA43880@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 4b. But sometimes we hit a different error. If another object points
> to X as a delta base, then trying to find the type of that object
> requires walking the delta chain to the base entry (since only the
> base has the concrete type; deltas themselves are either OFS_DELTA
> or REF_DELTA).
>
> Normally this would not require separate offset lookups at all, as
> deltas are usually stored as OFS_DELTA, specifying the relative
> offset to the base. But the corrupt idx created in step 1 is done
> directly with "git pack-objects" and does not pass the
> --delta-base-offset option, meaning we have REF_DELTA entries!
> Those do have to consult an index to find the location of the base
> object, and they use the pack .idx to do this. The same pack .idx
> that we know is corrupted from step 1!
Tricky.
> The set of objects created in the test is deterministic. But the delta
> selection seems not to be (which is not too surprising, as it is
> multi-threaded).
So, the offsets of the objects are also not deterministic?
> I have seen the failure in Windows CI but haven't
> reproduced it locally (not even with --stress). Re-running a failed
> Windows CI job tends to work. But when I download and examine the trash
> directory from a failed run, it shows a different set of deltas than I
> get locally. But the exact source of non-determinism isn't that
> important; our test should be robust against any order.
Yeah, thanks for digging this tricky situation through.
> b. The "objects64" setup could use --delta-base-offset. This would fix
> our problem, but earlier tests have many hard-coded offsets. Using
> OFS_DELTA would change the locations of objects in the pack (this
> might even be OK because I think most of the offsets are within the
> .idx file, but it seems brittle and I'm afraid to touch it).
I am not sure I follow, as it does not sound a solution to anything
if the offsets are not deterministic (and "earlier tests" that have
hard coded offsets are broken no matter what, which is not a problem
this patch introduces). Puzzled, but not curious enough to think
about it further, as you have already rejected this approach ;-)
> d. We could ask directly about object X, rather than enumerating all
> of them. But that requires further hard-coding of the oid (both
> sha1 and sha256) of object X. I'd prefer not to introduce more
> brittleness.
Right.
> e. We can use a --batch-check format that looks at the pack data, but
> doesn't have to chase deltas. The problem in this case is
> %(objecttype), which has to walk to the base. But %(objectsize)
> does not; we can get the value directly from the delta itself.
> Another option would be %(deltabase), where we report the REF_DELTA
> name but don't look at its data.
>
> I've gone with option (e) here. It's kind of subtle, but it's simple and
> has no side effects.
Nice.
> @@ -1129,8 +1129,10 @@ test_expect_success 'reader bounds-checks large offset table' '
> git multi-pack-index --object-dir=../objects64 write &&
> midx=../objects64/pack/multi-pack-index &&
> corrupt_chunk_file $midx LOFF clear &&
> - test_must_fail git cat-file \
> - --batch-check --batch-all-objects 2>err &&
> + # using only %(objectsize) is important here; see the commit
> + # message for more details
> + test_must_fail git cat-file --batch-all-objects \
> + --batch-check="%(objectsize)" 2>err &&
A rather unfriendly message to readers, as it is unclear which
commit you are talking about, and a fun thing is that you cannot
say which one.
Will queue. Thanks.
^ permalink raw reply
* Re: Bug: git grep --no-index 123 /dev/stdin crashes with SIGABRT
From: Kristoffer Haugsbakk @ 2023-10-14 19:37 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git, ks1322 ks1322
In-Reply-To: <2d8eca81-0415-43bf-b3c4-f1163713422b@app.fastmail.com>
On Sat, Oct 14, 2023, at 20:12, Kristoffer Haugsbakk wrote:
> It looks like `setup.c:verify_filename` fails to deny paths that are not
> transitive children (or whatever the term) of the directory that git(1) is
> running in:
No, that's not it. I don't think that's the responsibility of that
function. Compare to a successful run, that is when run in a Git
repository:
$ git grep --no-index dfddf /home
fatal: /home: '/home' is outside repository at '/home/kristoffer/programming/git'
And that error happens at `pathspec.c:473`.
So going down into that file is not wrong.
^ permalink raw reply
* Re: Bug: git grep --no-index 123 /dev/stdin crashes with SIGABRT
From: Kristoffer Haugsbakk @ 2023-10-14 18:12 UTC (permalink / raw)
To: ks1322 ks1322; +Cc: git
In-Reply-To: <CAKFQ_Q_P4HvCMHsg4=6ycb8r44qprhRCGSmLQf7B3_-zy28_oQ@mail.gmail.com>
Hi ks1322
On Sat, Oct 14, 2023, at 17:42, ks1322 ks1322 wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
> `git grep --no-index 123 /dev/stdin` outside of git repository
>
> What did you expect to happen? (Expected behavior)
> Ability to grep input from stdin
>
> What happened instead? (Actual behavior)
> `git grep` crashed with SIGABRT
>
> $ git grep --no-index 123 /dev/stdin
> BUG: environment.c:215: git environment hasn't been setup
> Aborted (core dumped)
>
> What's different between what you expected and what actually happened?
> Crash, no grep result
It looks like `setup.c:verify_filename` fails to deny paths that are not
transitive children (or whatever the term) of the directory that git(1) is
running in:
$ git -C ~/IdeaProjects/ grep --no-index dfddf ~
BUG: environment.c:213: git environment hasn't been setup
Aborted (core dumped)
So `builtin/grep.c` goes past that check, into
`pathspec.c:init_pathspec_item` and dies at line 472 since that function
assumes that we are in a Git repository.
--
Kristoffer Haugsbakk
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Dragan Simic @ 2023-10-14 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jacob Stopak, git
In-Reply-To: <xmqqa5slt7wa.fsf@gitster.g>
On 2023-10-14 19:45, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> writes:
>
>> How about making the filename a bit shorter first, to make room for
>> the additional two digits, so the example mentioned above would end up
>> being named "git-bugreport-20231014-092037.txt"?
>
> The reason I stated not to unconditionally add two more digits is
> *not* that I wanted to keep things shorter. I wanted to keep names
> stable and in the same shape as before for sensible people who spend
> more than 60 seconds---only those who produce more than one within
> the same minute will be affected.
>
> What is your reason to want to make the filename shoter first?
> It would break everybody, wouldn't it?
Please note that I haven't researched in detail what else depends on the
current filename format, which presumably is a whole bunch of stuff, I
just suggested this filename compaction because I understood that the
filename length was becoming an issue.
Speaking in general, I somehow find "20220712" a bit more readable than
"2022-07-12" as part of a filename, but that's of course just my
personal preference.
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Junio C Hamano @ 2023-10-14 17:45 UTC (permalink / raw)
To: Dragan Simic; +Cc: Jacob Stopak, git
In-Reply-To: <833da2d05d4b1dfa8e561aa638a927b0@manjaro.org>
Dragan Simic <dsimic@manjaro.org> writes:
> How about making the filename a bit shorter first, to make room for
> the additional two digits, so the example mentioned above would end up
> being named "git-bugreport-20231014-092037.txt"?
The reason I stated not to unconditionally add two more digits is
*not* that I wanted to keep things shorter. I wanted to keep names
stable and in the same shape as before for sensible people who spend
more than 60 seconds---only those who produce more than one within
the same minute will be affected.
What is your reason to want to make the filename shoter first?
It would break everybody, wouldn't it?
^ permalink raw reply
* Re: [RFC] Define "precious" attribute and support it in `git clean`
From: Junio C Hamano @ 2023-10-14 17:41 UTC (permalink / raw)
To: Josh Triplett; +Cc: Sebastian Thiel, git
In-Reply-To: <ZSouSI_zPusOefsv@localhost>
Josh Triplett <josh@joshtriplett.org> writes:
> On Tue, Oct 10, 2023 at 10:02:20AM -0700, Junio C Hamano wrote:
>> Sebastian Thiel <sebastian.thiel@icloud.com> writes:
>>
>> > I'd like to propose adding a new standard gitattribute "precious".
>>
>> ;-).
>>
>> Over the years, I've seen many times scenarios that would have been
>> helped if we had not just "tracked? ignored? unignored?" but also
>> the fourth kind [*]. The word "ignored" (or "excluded") has always
>> meant "not tracked, not to be tracked, and expendable" to Git, and
>> "ignored but unexpendable" class was missing. I even used the term
>> "precious" myself in those discussions. At the concept level, I
>> support the effort 100%, but as always, the devil will be in the
>> details.
>
> "I've already wanted this for years" is, honestly, the best response we
> could *possibly* have hoped for.
Yeah, but that is not what I gave here.
It is something I saw people want from time to time over the years;
I am not at all talking about my desire, or lack thereof, to add it
to the system ;-)
>> In previous discussions, nobody was disturbed that "git clean" was
>> unaware of the "precious" class, but if we were to have the
>> "precious" class in addition to "ignored" aka "expendable", I would
>> not oppose to teach "git clean" about it, too.
>>
>> There was an early and rough design draft there in
>>
>> https://lore.kernel.org/git/7vipsnar23.fsf@alter.siamese.dyndns.org/
>>
>> which probably is worth a read, too.
The project can say something like
# force older git to ignore
.config
# older git unignores "$.config" without touching ".config"
# but newer git applies the "last one wins" rule as usual
# to mark ".config" as precious.
!$.config
if our syntax were to retrofit '!' prefix, and even more simply
#:(precious)
.config
if we adopt Phillip's "comment abuse" idea, where older Git will
treat it as saying ".config" is not to be added but is expendable,
while newer Git will treat it as saying ".config" is not to be added
and not to be clobbered.
^ permalink raw reply
* Re: Bug: git diagnose crashes with Segmentation fault outside of git repository
From: Christian Couder @ 2023-10-14 17:22 UTC (permalink / raw)
To: ks1322 ks1322; +Cc: git, Victoria Dye
In-Reply-To: <CAKFQ_Q9WjF9i-Rx2jdCw-adPVQrWNfNKrDY-em8Rpa5RNLXz4A@mail.gmail.com>
On Sat, Oct 14, 2023 at 2:00 PM ks1322 ks1322 <ks1322@gmail.com> wrote:
>
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
> Run `git diagnose` outside of any git repository
>
> What did you expect to happen? (Expected behavior)
> No crash, reasonable diagnose output
>
> What happened instead? (Actual behavior)
> `git diagnose` crashed with Segmentation fault
>
> $ git diagnose
> Collecting diagnostic info
>
> git version 2.41.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> Repository root: (null)
> Available space on '/tmp': 7.75 GiB (mount flags 0x6)
> Segmentation fault (core dumped)
Yeah, this is a valid bug report that I can reproduce. It looks like
such bugs have existed in this command since it was created last year.
Best,
Christian.
^ permalink raw reply
* Re: [PATCH] diagnose: require repository
From: Junio C Hamano @ 2023-10-14 17:15 UTC (permalink / raw)
To: Martin Ågren; +Cc: ks1322 ks1322, git, Victoria Dye
In-Reply-To: <20231014135302.13095-1-martin.agren@gmail.com>
Martin Ågren <martin.agren@gmail.com> writes:
> When `git diagnose` is run from outside a repo, it begins collecting
> various information before eventually hitting a segmentation fault,
> leaving an incomplete zip file behind.
>
> Switch from the gentle setup to requiring a git directory. Without a git
> repo, there isn't really much to diagnose.
>
> We could possibly do a best-effort collection of information about the
> machine and then give up. That would roughly be today's behavior but
> with a controlled exit rather than a segfault. However, the purpose of
> this tool is largely to create a zip archive. Rather than creating an
> empty zip file or no zip file at all, and having to explain that
> behavior, it seems more helpful to bail out clearly and early with a
> succinct error message.
Without having thought things through, offhand I agree with your "no
repository? there is nothing worth tarring up then" assessment.
Because "git bugreport --diag" unconditionally spawns "git
diagnose", the former may also want to be extra careful, perhaps
like the attached patch.
builtin/bugreport.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git c/builtin/bugreport.c w/builtin/bugreport.c
index d2ae5c305d..ac9e05fcf7 100644
--- c/builtin/bugreport.c
+++ w/builtin/bugreport.c
@@ -146,6 +146,11 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
report_path.buf);
}
+ if (!startup_info->have_repository && diagnose != DIAGNOSE_NONE) {
+ warning(_("no repository--diagnostic output disabled"));
+ diagnose = DIAGNOSE_NONE;
+ }
+
/* Prepare diagnostics, if requested */
if (diagnose != DIAGNOSE_NONE) {
struct strbuf zip_path = STRBUF_INIT;
^ permalink raw reply related
* Re: [Outreachy Applicant]
From: Christian Couder @ 2023-10-14 16:41 UTC (permalink / raw)
To: estherugbiedah@gmail.com; +Cc: git@vger.kernel.org
In-Reply-To: <355182457.15373219.1697222676128@mail.yahoo.com>
Hi,
On Fri, Oct 13, 2023 at 8:44 PM estherugbiedah@gmail.com
<estherugbiedah@gmail.com> wrote:
>
> Hello Git Community,
>
> I am an Outreachy applicant for the 2023 cohort and I am thrilled to contribute to the Git project.
Thanks for your interest in Git and welcome to the Git community!
> Having reviewed the available projects, I am particularly interested in this project. I believe that contributing to this project will not only enhance my skills but also allow me to make a meaningful impact.
>
> I am ready and excited to immerse myself in the project and make valuable contributions.
Great, please take a look at the documentation we have on
https://git.github.io/, especially the pages and sections I mention
below.
First, we require that applicants make a small code contribution (we
call that a micro-project) to the Git project. This is explained here:
https://git.github.io/General-Microproject-Information/
and there is information about how to find micro-project ideas.
Now we have recently added a "Thoroughly check your eligibility in the
program" sub-section to that page. Please read it, check your
eligibility and confirm that you meet all the requirements soon.
Then there are links to tutorials and a number of other useful link
for Git developers on this page:
https://git.github.io/Hacking-Git/
Also the following page is useful as it contains more general
information about how to apply:
https://git.github.io/General-Application-Information/
Best,
Christian.
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Dragan Simic @ 2023-10-14 16:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jacob Stopak, git
In-Reply-To: <xmqq4jitw4nk.fsf@gitster.g>
On 2023-10-14 18:27, Junio C Hamano wrote:
> Jacob Stopak <jacob@initialcommit.io> writes:
>> If a user runs the bugreport command more than once within a calendar
>> minute, a filename conflict with an existing file occurs and the
>> program
>> errors, since the new output filename was already used for the
>> previous
>> file.
>
> This is totally expected and you made an excellent observation.
>
> I personally do not think it is a problem, simply because a quality
> bug report that would capture information necessary to diagnose any
> issue concisely in a readable fashion would take at least 90 seconds
> or more to produce, though.
>
> Instead of lengthening the filename for all files by 2 digits, the
> command can retry by adding say "+1", "+2", etc. after the failed
> filename to find a unique suffix within the same minute. It would
> mean that after writing git-bugreport-2023-10-14-0920.txt and you
> start another one without spending enough time, the new one may
> become git-bugreport-2023-10-14-0920+1.txt or something unique.
How about making the filename a bit shorter first, to make room for the
additional two digits, so the example mentioned above would end up being
named "git-bugreport-20231014-092037.txt"?
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Junio C Hamano @ 2023-10-14 16:27 UTC (permalink / raw)
To: Jacob Stopak; +Cc: git
In-Reply-To: <20231014040101.8333-1-jacob@initialcommit.io>
Jacob Stopak <jacob@initialcommit.io> writes:
> Currently, git bugreport postfixes the default bugreport filename (and
> diagnostics zip filename if --diagnose is supplied) with the current
> calendar hour and minute values, assuming the -s flag is absent.
Is "postfix" a verb that is commonly understood? I would say
"append" would be understood by more readers. Also, is "calendar"
hour different from other kinds of hours, perhaps stopwatch hours
and microwave-oven hours?
> If a user runs the bugreport command more than once within a calendar
> minute, a filename conflict with an existing file occurs and the program
> errors, since the new output filename was already used for the previous
> file.
This is totally expected and you made an excellent observation.
I personally do not think it is a problem, simply because a quality
bug report that would capture information necessary to diagnose any
issue concisely in a readable fashion would take at least 90 seconds
or more to produce, though.
Instead of lengthening the filename for all files by 2 digits, the
command can retry by adding say "+1", "+2", etc. after the failed
filename to find a unique suffix within the same minute. It would
mean that after writing git-bugreport-2023-10-14-0920.txt and you
start another one without spending enough time, the new one may
become git-bugreport-2023-10-14-0920+1.txt or something unique. It
would be really unlikely that you would run out after failing to
find a vacant single digit suffix nine times, i.e. trying "+9". It
would also help preserve existing user's workflow, e.g. they may
have written automation that assumes the down-to-minute format and
it would keep working on their bug reports without breaking.
^ permalink raw reply
* Re: [RFC] Define "precious" attribute and support it in `git clean`
From: Junio C Hamano @ 2023-10-14 16:10 UTC (permalink / raw)
To: Phillip Wood; +Cc: Sebastian Thiel, git, Josh Triplett, Kristoffer Haugsbakk
In-Reply-To: <0deee2bc-1775-4459-906d-1d44b3103499@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> One thought I had was that we could abuse the comment syntax to
> annotate paths something like
>
> #(keep)
> /my-precious-file
>
> would prevent /my-precious-file from being deleted by git clean (and
> hopefully unpack-trees()[1]). It means that older versions of git
> would treat the file as ignored. If we ever want more than one
> annotation per path we could separate them with commas
>
> #(keep,something-else)
> /my-file
>
> Strictly speaking it is a backward incompatible change but I doubt
> there are many people using comments like that.
;-)
If "#(" feels a bit too generic, that part can be bikeshed.
I might find some example use cases why we shouldn't later, but
offhand, the idea of (ab)using the comment is a very good idea.
^ permalink raw reply
* Re: [PATCH 5/8] commit-graph: read `BIDX` chunk with `pair_chunk_expect()`
From: Junio C Hamano @ 2023-10-14 16:10 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, Jeff King
In-Reply-To: <45cac29403e63483951f7766c6da3c022c68d9f0.1697225110.git.me@ttaylorr.com>
Taylor Blau <me@ttaylorr.com> writes:
> -static int graph_read_bloom_index(const unsigned char *chunk_start,
> - size_t chunk_size, void *data)
> -{
> - struct commit_graph *g = data;
> - if (chunk_size != g->num_commits * 4) {
> - warning("commit-graph changed-path index chunk is too small");
> - return -1;
> - }
> ...
> @@ -461,8 +449,10 @@ struct commit_graph *parse_commit_graph(struct repo_settings *s,
> }
>
> if (s->commit_graph_read_changed_paths) {
> + if (pair_chunk_expect(cf, GRAPH_CHUNKID_BLOOMINDEXES,
> + &graph->chunk_bloom_indexes,
> + st_mult(graph->num_commits, 4)) == -1)
> + warning(_("commit-graph changed-path index chunk is too small (%d)"), graph->num_commits * 4);
> read_chunk(cf, GRAPH_CHUNKID_BLOOMDATA,
> graph_read_bloom_data, graph);
> }
Overall the series looked sane, but the need for each caller to
supply error messages, when the helper perfectly well knows how many
bytes the caller expected and how many bytes there are avaiable, was
a bit disturbing, as the level of detail given per each caller will
inevitably become uneven. Even now, some give an error() while
others give a warning(), even though I suspect all of them should be
data errors.
I wonder if it makes sense to stuff the message template in the
pair_chunk_data structure and do
static int pair_chunk_expect_fn(const unsigned char *chunk_start,
size_t chunk_size,
void *data)
{
struct pair_chunk_data *pcd = data;
if (pcd->expected_size != chunk_size)
return error(_(pcd->message), pcd->expected_size, chunk_size);
*pcd->p = chunk_start;
return 0;
}
^ permalink raw reply
* Bug: git grep --no-index 123 /dev/stdin crashes with SIGABRT
From: ks1322 ks1322 @ 2023-10-14 15:42 UTC (permalink / raw)
To: git
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
`git grep --no-index 123 /dev/stdin` outside of git repository
What did you expect to happen? (Expected behavior)
Ability to grep input from stdin
What happened instead? (Actual behavior)
`git grep` crashed with SIGABRT
$ git grep --no-index 123 /dev/stdin
BUG: environment.c:215: git environment hasn't been setup
Aborted (core dumped)
What's different between what you expected and what actually happened?
Crash, no grep result
Anything else you want to add:
Plain grep can do that, so I suppose `git grep` could also:
$ echo -e "123\n456\n789" | grep 456 /dev/stdin
456
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.41.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.5.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 6
19:02:35 UTC 2023 x86_64
compiler info: gnuc: 13.1
libc info: glibc: 2.37
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
not run from a git repository - no hooks to show
^ permalink raw reply
* Re: [PATCH] diagnose: require repository
From: Kristoffer Haugsbakk @ 2023-10-14 14:56 UTC (permalink / raw)
To: Martin Ågren; +Cc: git, Victoria Dye, ks1322 ks1322
In-Reply-To: <20231014135302.13095-1-martin.agren@gmail.com>
On Sat, Oct 14, 2023, at 15:53, Martin Ågren wrote:
> Switch from the gentle setup to requiring a git directory. Without a git
> repo, there isn't really much to diagnose.
This patch works for me. Thanks.
--
Kristoffer Haugsbakk
^ permalink raw reply
* [PATCH] diagnose: require repository
From: Martin Ågren @ 2023-10-14 13:53 UTC (permalink / raw)
To: ks1322 ks1322; +Cc: git, Victoria Dye
In-Reply-To: <CAKFQ_Q9WjF9i-Rx2jdCw-adPVQrWNfNKrDY-em8Rpa5RNLXz4A@mail.gmail.com>
When `git diagnose` is run from outside a repo, it begins collecting
various information before eventually hitting a segmentation fault,
leaving an incomplete zip file behind.
Switch from the gentle setup to requiring a git directory. Without a git
repo, there isn't really much to diagnose.
We could possibly do a best-effort collection of information about the
machine and then give up. That would roughly be today's behavior but
with a controlled exit rather than a segfault. However, the purpose of
this tool is largely to create a zip archive. Rather than creating an
empty zip file or no zip file at all, and having to explain that
behavior, it seems more helpful to bail out clearly and early with a
succinct error message.
Reported-by: ks1322 ks1322 <ks1322@gmail.com>
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
Thanks for the report. This could be one way of fixing this.
I haven't found anything in the original submission [1] discussing this
"_GENTLY". I didn't see anything in the implementation or the tests
suggesting that it was intentional to run outside a git repo.
[1] https://lore.kernel.org/git/xmqqzgg1nz6v.fsf@gitster.g/t/#mc66904caab6bc79e57eaf5063df268b2725b6fcc
t/t0092-diagnose.sh | 5 +++++
git.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/t/t0092-diagnose.sh b/t/t0092-diagnose.sh
index 133e5747d6..49671d35a2 100755
--- a/t/t0092-diagnose.sh
+++ b/t/t0092-diagnose.sh
@@ -5,6 +5,11 @@ test_description='git diagnose'
TEST_PASSES_SANITIZE_LEAK=true
. ./test-lib.sh
+test_expect_success 'nothing to diagnose without repo' '
+ nongit test_must_fail git diagnose 2>err &&
+ grep "not a git repository" err
+'
+
test_expect_success UNZIP 'creates diagnostics zip archive' '
test_when_finished rm -rf report &&
diff --git a/git.c b/git.c
index c67e44dd82..ff04a74bbd 100644
--- a/git.c
+++ b/git.c
@@ -525,7 +525,7 @@ static struct cmd_struct commands[] = {
{ "credential-cache--daemon", cmd_credential_cache_daemon },
{ "credential-store", cmd_credential_store },
{ "describe", cmd_describe, RUN_SETUP },
- { "diagnose", cmd_diagnose, RUN_SETUP_GENTLY },
+ { "diagnose", cmd_diagnose, RUN_SETUP },
{ "diff", cmd_diff, NO_PARSEOPT },
{ "diff-files", cmd_diff_files, RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
{ "diff-index", cmd_diff_index, RUN_SETUP | NO_PARSEOPT },
--
2.42.0.399.g85a82e71e0
^ permalink raw reply related
* Bug: git diagnose crashes with Segmentation fault outside of git repository
From: ks1322 ks1322 @ 2023-10-14 11:59 UTC (permalink / raw)
To: git
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Run `git diagnose` outside of any git repository
What did you expect to happen? (Expected behavior)
No crash, reasonable diagnose output
What happened instead? (Actual behavior)
`git diagnose` crashed with Segmentation fault
$ git diagnose
Collecting diagnostic info
git version 2.41.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
Repository root: (null)
Available space on '/tmp': 7.75 GiB (mount flags 0x6)
Segmentation fault (core dumped)
What's different between what you expected and what actually happened?
Segmentation fault, truncated output
Anything else you want to add:
`git diagnose` does not crash when run within some git repository
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.41.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.5.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 6
19:02:35 UTC 2023 x86_64
compiler info: gnuc: 13.1
libc info: glibc: 2.37
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
not run from a git repository - no hooks to show
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Kristoffer Haugsbakk @ 2023-10-14 10:35 UTC (permalink / raw)
To: Jacob Stopak; +Cc: git
In-Reply-To: <20231014040101.8333-1-jacob@initialcommit.io>
Hi Jacob
On Sat, Oct 14, 2023, at 06:01, Jacob Stopak wrote:
> This patch adds the calendar second value to the default bugreport
Nitpick: you can just say “Add the calendar”. “This patch” is redundant.
See `Documentation/SubmittingPatches` at `imperative-mood`.
--
Kristoffer
^ permalink raw reply
* Re: [RFC] Define "precious" attribute and support it in `git clean`
From: Sebastian Thiel @ 2023-10-14 7:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Josh Triplett, Kristoffer Haugsbakk
In-Reply-To: <xmqqfs2e3292.fsf@gitster.g>
On 13 Oct 2023, at 18:39, Junio C Hamano wrote:
> Come to think of it, we might be able to retrofit '!' without too
> much damage. Something like "!unignored" is now a deprecated but
> still supported way to say "!!unignored", "!*precious" is new, and
> "\!anything" is a pathname that begins with '!'.
I don't know anything about statistics, and I don't which of the proposed
syntax thus far has the lowest probability of accidental breakage, possibly
in combination with the best possible usability.
However, I do like even more the idea to retro-fit `!` instead of having an
entirely new prefix, it seems more intuitive to me.
An apparent disadvantage would be that using `!` prefix with
backwards-compatibility will make any additional future modifier more
breaking. For instance `!*` is potentially ignoring an additional file
in old git, and another `!-` modifier is having the same effect.
Chances for this are probably low though, but if in doubt it would be possible
to check certain patterns against all files of the top-3.5TB of
GitHub repositories.
Using `!*` to signal precious files also seems like a less likely
path prefix than `!$` would be, but then again, it's just a guess
which most definitely doesn't have much bearing.
I personally also like this more than using special comments as 'modifier',
even though doing so would probably have the lowest probability for
accidentally ignoring files in old git.
Maybe it's time to choose one of the options with the possibility to validate
it for accidental exclusion of files against the top 3.5TB of
GitHub repositories to be more sure it?
^ permalink raw reply
* Re: [RFC] Define "precious" attribute and support it in `git clean`
From: Josh Triplett @ 2023-10-14 5:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sebastian Thiel, git
In-Reply-To: <xmqqttqytnqb.fsf@gitster.g>
On Tue, Oct 10, 2023 at 10:02:20AM -0700, Junio C Hamano wrote:
> Sebastian Thiel <sebastian.thiel@icloud.com> writes:
>
> > I'd like to propose adding a new standard gitattribute "precious".
>
> ;-).
>
> Over the years, I've seen many times scenarios that would have been
> helped if we had not just "tracked? ignored? unignored?" but also
> the fourth kind [*]. The word "ignored" (or "excluded") has always
> meant "not tracked, not to be tracked, and expendable" to Git, and
> "ignored but unexpendable" class was missing. I even used the term
> "precious" myself in those discussions. At the concept level, I
> support the effort 100%, but as always, the devil will be in the
> details.
"I've already wanted this for years" is, honestly, the best response we
could *possibly* have hoped for.
> Scenarios that people wished for "precious" traditionally have been
>
> * You are working on 'master'. You have in your .gitignore or
> .git/info/exclude a line to ignore path A, and have random
> scribbles in a throw-away file there. There is another branch
> 'seen', where they added some tracked contents at path A/B. You
> do "git checkout seen" and your file A that is an expendable file,
> because it is listed as ignored in .git/info/exclude, is removed
> to make room for creating A/B.
Ouch, I hadn't even thought about the issue of branch-switching
overwriting a file like that, but that's another great reason to have
"precious". (I've been thinking about "precious" as primarily to protect
files like `.config`, where they'd be unlikely to be checked in on any
branch because they have an established purpose in the project. Though,
of course, people *do* sometimes check in `.config` files in
special-purpose branches that aren't meant for upstreaming.)
> * Similar situation, but this time, 'seen' branch added a tracked
> contents at path A. Again, "git checkout seen" will discard the
> expendable file A and replace it with tracked contents.
>
> * Instead of "git checkout", you decide to merge the branch 'seen'
> to the checkout of 'master', where you have an ignored path A.
> Because merging 'seen' would need to bring the tracked contents
> of either A/B (in the first scenario above) or A (in the second
> scenario), your "expendable" A will be removed to make room.
+1
> In previous discussions, nobody was disturbed that "git clean" was
> unaware of the "precious" class, but if we were to have the
> "precious" class in addition to "ignored" aka "expendable", I would
> not oppose to teach "git clean" about it, too.
>
> There was an early and rough design draft there in
>
> https://lore.kernel.org/git/7vipsnar23.fsf@alter.siamese.dyndns.org/
>
> which probably is worth a read, too.
>
> Even though I referred to the precious _attribute_ in some of these
> discussions, between the attribute mechanism and the ignore
> mechanism, I am actually leaning toward suggesting to extend the
> exclude/ignore mechanism to introduce the "precious" class. That
> way, we can avoid possible snafu arising from marking a path in
> .gitignore as ignored, and in .gitattrbutes as precious, and have to
> figure out how these two settings are to work together.
Sounds reasonable.
> In any case, the "precious" paths are expected to be small minority
> of what people never want to "git add" or "git commit", so coming up
> with a special syntax to be used in .gitignore, even if that special
> syntax is ugly and cumbersome to type, would be perfectly OK.
[Following up both to this and to Sebastian's response.]
One potentially important question: should the behavior of old git be to
treat precious files as ignored, or as not-ignored? If the syntax were
something like
$.config
then old git would treat the file as not-ignored. If the syntax were
something like
$precious
.config
then old git would treat the file as ignored.
Seems like it would be obtrusive if `git status` in old git showed the
file, and `git add .` in old git added it.
^ permalink raw reply
* [PATCH] bugreport: add 'seconds' to default outfile name
From: Jacob Stopak @ 2023-10-14 4:01 UTC (permalink / raw)
To: git; +Cc: Jacob Stopak
Currently, git bugreport postfixes the default bugreport filename (and
diagnostics zip filename if --diagnose is supplied) with the current
calendar hour and minute values, assuming the -s flag is absent.
If a user runs the bugreport command more than once within a calendar
minute, a filename conflict with an existing file occurs and the program
errors, since the new output filename was already used for the previous
file. If the user waits anywhere from 1 to 60 seconds (depending on
_when_ during the calendar minute the first command was run) the command
works again with no error since the default filename is now unique, and
multiple bug reports are able to be created with default settings.
This is a minor thing but can cause confusion especially for first time
users of the bugreport command, who are likely to run it multiple times
in quick succession to learn how it works, (like I did).
This patch adds the calendar second value to the default bugreport
filename. This technically just shortens the window during which the
issue occurs, but a single second is a small enough time increment that
users will avoid the filename conflict in practice in this scenario.
This means the user will end up with multiple bugreport files being
created if they run the command multiple times quickly, but that feels
more intuitive and consistent than an error arbitrarily occuring within
a calendar minute, especially given that the time window in which the
error currently occurs is variable as described above.
Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
---
builtin/bugreport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/bugreport.c b/builtin/bugreport.c
index d2ae5c305d..b556c6e135 100644
--- a/builtin/bugreport.c
+++ b/builtin/bugreport.c
@@ -106,7 +106,7 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
struct tm tm;
enum diagnose_mode diagnose = DIAGNOSE_NONE;
char *option_output = NULL;
- char *option_suffix = "%Y-%m-%d-%H%M";
+ char *option_suffix = "%Y-%m-%d-%H%M%S";
const char *user_relative_path = NULL;
char *prefixed_filename;
size_t output_path_len;
base-commit: 493f4622739e9b64f24b465b21aa85870dd9dc09
--
2.42.0.297.g393e7d1581
^ permalink raw reply related
* [PATCH 21/20] t5319: make corrupted large-offset test more robust
From: Jeff King @ 2023-10-14 0:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Taylor Blau
In-Reply-To: <20231009205544.GA3281950@coredump.intra.peff.net>
On Mon, Oct 09, 2023 at 04:55:44PM -0400, Jeff King wrote:
> [10/20]: midx: bounds-check large offset chunk
Here's one more patch on top that fixes a flaky test. Sorry not to have
caught it before sending out the original series. I did see a flaky CI
run before then, but I tweaked the test with what I thought was the
solution, and then it didn't re-occur until I ran CI again today.
I'm pretty sure this should fix it for good.
(I also saw Taylor posted some further patches; I haven't looked closely
yet, this should be orthogonal to those).
-- >8 --
Subject: [PATCH] t5319: make corrupted large-offset test more robust
The test t5319.88 ("reader bounds-checks large offset table") can fail
intermittently. The failure mode looks like this:
1. An earlier test sets up "objects64", a directory that can be used
to produce a midx with a corrupted large-offsets table. To get the
large offsets, it corrupts the normal ".idx" file to have a fake
large offset, and then builds a midx from that.
That midx now has a large offset table, which is what we want. But
we also have a .idx on disk that has a corrupted entry. We'll call
the object with the corrupted large-offset "X".
2. In t5319.88, we further corrupt the midx by reducing the size of
the large-offset chunk (because our goal is to make sure we do not
do an out-of-bounds read on it).
3. We then enumerate all of the objects with "cat-file --batch-check
--batch-all-objects", expecting to see a complaint when we try to
show object X. We use --batch-all-objects because our objects64
repo doesn't actually have any refs (but if we check them all, one
of them will be the failing one). The default batch-check format
includes %(objecttype) and %(objectsize), both of which require us
to access the actual pack data (and thus requires looking at the
offset).
4a. Usually, this succeeds. We try to output object X, do a lookup via
the midx for the type/size lookup, and run into the corrupt
large-offset table.
4b. But sometimes we hit a different error. If another object points
to X as a delta base, then trying to find the type of that object
requires walking the delta chain to the base entry (since only the
base has the concrete type; deltas themselves are either OFS_DELTA
or REF_DELTA).
Normally this would not require separate offset lookups at all, as
deltas are usually stored as OFS_DELTA, specifying the relative
offset to the base. But the corrupt idx created in step 1 is done
directly with "git pack-objects" and does not pass the
--delta-base-offset option, meaning we have REF_DELTA entries!
Those do have to consult an index to find the location of the base
object, and they use the pack .idx to do this. The same pack .idx
that we know is corrupted from step 1!
Git does notice the error, but it does so by seeing the corrupt
.idx file, not the corrupt midx file, and the error it reports is
different, causing the test to fail.
The set of objects created in the test is deterministic. But the delta
selection seems not to be (which is not too surprising, as it is
multi-threaded). I have seen the failure in Windows CI but haven't
reproduced it locally (not even with --stress). Re-running a failed
Windows CI job tends to work. But when I download and examine the trash
directory from a failed run, it shows a different set of deltas than I
get locally. But the exact source of non-determinism isn't that
important; our test should be robust against any order.
There are a few options to fix this:
a. It would be OK for the "objects64" setup to "unbreak" the .idx file
after generating the midx. But then it would be hard for subsequent
tests to reuse it, since it is the corrupted idx that forces the
midx to have a large offset table.
b. The "objects64" setup could use --delta-base-offset. This would fix
our problem, but earlier tests have many hard-coded offsets. Using
OFS_DELTA would change the locations of objects in the pack (this
might even be OK because I think most of the offsets are within the
.idx file, but it seems brittle and I'm afraid to touch it).
c. Our cat-file output is in oid order by default. Since we store
bases before deltas, if we went in pack order (using the
"--unordered" flag), we'd always see our corrupt X before any delta
which depends on it. But using "--unordered" means we skip the midx
entirely. That makes sense, since it is just enumerating all of
the packs, using the offsets found in their .idx files directly.
So it doesn't work for our test.
d. We could ask directly about object X, rather than enumerating all
of them. But that requires further hard-coding of the oid (both
sha1 and sha256) of object X. I'd prefer not to introduce more
brittleness.
e. We can use a --batch-check format that looks at the pack data, but
doesn't have to chase deltas. The problem in this case is
%(objecttype), which has to walk to the base. But %(objectsize)
does not; we can get the value directly from the delta itself.
Another option would be %(deltabase), where we report the REF_DELTA
name but don't look at its data.
I've gone with option (e) here. It's kind of subtle, but it's simple and
has no side effects.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t5319-multi-pack-index.sh | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t5319-multi-pack-index.sh b/t/t5319-multi-pack-index.sh
index 2a11dd1af6..d3c9e97feb 100755
--- a/t/t5319-multi-pack-index.sh
+++ b/t/t5319-multi-pack-index.sh
@@ -1129,8 +1129,10 @@ test_expect_success 'reader bounds-checks large offset table' '
git multi-pack-index --object-dir=../objects64 write &&
midx=../objects64/pack/multi-pack-index &&
corrupt_chunk_file $midx LOFF clear &&
- test_must_fail git cat-file \
- --batch-check --batch-all-objects 2>err &&
+ # using only %(objectsize) is important here; see the commit
+ # message for more details
+ test_must_fail git cat-file --batch-all-objects \
+ --batch-check="%(objectsize)" 2>err &&
cat >expect <<-\EOF &&
fatal: multi-pack-index large offset out of bounds
EOF
--
2.42.0.937.g4d9eb42d36
^ permalink raw reply related
* Re: [PATCH] Add x64 SHA-NI implementation to sha1 and sha256 in git ?
From: Junio C Hamano @ 2023-10-14 0:29 UTC (permalink / raw)
To: brian m. carlson; +Cc: Feiyang Xue, git
In-Reply-To: <ZSmxFopwJyBGmZY-@tapette.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> If we ship the code, then someone has to maintain it, and I don't know
> if we have any assembly experts. We might also have a bug that produced
> incorrect results, which would be pretty disastrous for the affected
> users. It's much better for maintainability if we push that off onto
> the cryptographic library maintainers who are much more competent in
> that regard than I am (I will not speak for others) and let distro
> maintainers simply link the appropriate library, which, as I said above,
> they're already effectively doing.
Thanks for a well reasoned response. Very much appreciated.
^ permalink raw reply
* Re: [PATCH] Add x64 SHA-NI implementation to sha1 and sha256 in git ?
From: brian m. carlson @ 2023-10-13 21:05 UTC (permalink / raw)
To: Feiyang Xue; +Cc: git
In-Reply-To: <20231012200447.3553757-1-hi@fxue.dev>
[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]
On 2023-10-12 at 20:04:47, Feiyang Xue wrote:
> Looking for comments on if this is a good idea to add SHA-NI option to git,
> And if so, what'd be a good implementation.
>
> The attached patch is more of a proof of concept, using a sha-ni example
> found on internet and have it tapped into git's "hash-ll.h" when it sees make
> flags "SHA1_SHANI=1" and/or "SHA256_SHANI=1" for sha1/sha256 respectively.
>
> "git hash-object" is about 3-ish times faster for me
You almost certainly don't want to use SHA-1 using native instructions
because it doesn't detect collisions, unlike the default implementation
(SHA-1-DC). Since SHA-1 collisions are relatively cheap (less than USD
45,000) to make, not detecting collisions would be a security issue
worthy of a CVE.
It's fine for SHA-256, but see below.
> There are few topics that i'm uncertain about.
>
> 1. Is it good idea to have machine-specific asm codes in git. I read there was
> commit fd1ec82547 which removed assembly implementation for PPC_SHA1. Does that
> imply maintainers doesn't want machine-specific assembly in source?
I'd prefer we didn't.
Nettle has SHA-NI extensions on systems that support it, and so does
OpenSSL. OpenSSL can't be used by distros for licensing reasons, but
Nettle can, and both of those libraries automatically detect the best
code to use based on the chip. One of those libraries is almost always
going to be linked into Git at some point because of libcurl anyway.
If we ship the code, then someone has to maintain it, and I don't know
if we have any assembly experts. We might also have a bug that produced
incorrect results, which would be pretty disastrous for the affected
users. It's much better for maintainability if we push that off onto
the cryptographic library maintainers who are much more competent in
that regard than I am (I will not speak for others) and let distro
maintainers simply link the appropriate library, which, as I said above,
they're already effectively doing.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox