* What's cooking in git.git (Mar 2024, #02; Thu, 7)
From: Junio C Hamano @ 2024-03-08 2:26 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).
The 'maint' branch now points at the 2.44 maintenance track.
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']
* ak/rebase-autosquash (2024-02-27) 1 commit
(merged to 'next' on 2024-03-01 at 57a34830b7)
+ rebase: fix typo in autosquash documentation
Originally merged to 'next' on 2024-02-27
Typofix.
source: <pull.1676.git.1709015578890.gitgitgadget@gmail.com>
* cc/rev-list-allow-missing-tips (2024-02-28) 5 commits
(merged to 'next' on 2024-03-01 at fd7b109d04)
+ revision: fix --missing=[print|allow*] for annotated tags
(merged to 'next' on 2024-03-01 at ac0fc94378)
+ rev-list: allow missing tips with --missing=[print|allow*]
+ t6022: fix 'test' style and 'even though' typo
+ oidset: refactor oidset_insert_from_set()
+ revision: clarify a 'return NULL' in get_reference()
Originally merged to 'next' on 2024-02-28
"git rev-list --missing=print" has learned to optionally take
"--allow-missing-tips", which allows the objects at the starting
points to be missing.
source: <20240214142513.4002639-1-christian.couder@gmail.com>
* eg/add-uflags (2024-02-29) 1 commit
(merged to 'next' on 2024-03-01 at 5dbc997561)
+ add: use unsigned type for collection of bits
Originally merged to 'next' on 2024-02-29
Code clean-up practice.
source: <20240229194444.8499-2-giganteeugenio2@gmail.com>
* jc/doc-compat-util (2024-02-27) 1 commit
(merged to 'next' on 2024-03-01 at 89b76c65d7)
+ doc: clarify the wording on <git-compat-util.h> requirement
Originally merged to 'next' on 2024-02-27
Clarify wording in the CodingGuidelines that requires <git-compat-util.h>
to be the first header file.
source: <xmqqle76kdpr.fsf_-_@gitster.g>
* jc/no-include-of-compat-util-from-headers (2024-02-24) 1 commit
(merged to 'next' on 2024-03-01 at ebb921087e)
+ compat: drop inclusion of <git-compat-util.h>
Originally merged to 'next' on 2024-02-26
Header file clean-up.
source: <xmqqwmqtli18.fsf@gitster.g>
* jc/no-lazy-fetch (2024-02-27) 3 commits
(merged to 'next' on 2024-03-01 at 14303cdbfe)
+ git: extend --no-lazy-fetch to work across subprocesses
+ git: document GIT_NO_REPLACE_OBJECTS environment variable
+ git: --no-lazy-fetch option
Originally merged to 'next' on 2024-02-29
"git --no-lazy-fetch cmd" allows to run "cmd" while disabling lazy
fetching of objects from the promisor remote, which may be handy
for debugging.
source: <xmqq1q8xx38i.fsf@gitster.g>
source: <xmqq1q9cl3xv.fsf@gitster.g>
source: <xmqq1q9mmtpw.fsf@gitster.g>
* jk/reflog-special-cases-fix (2024-02-26) 3 commits
(merged to 'next' on 2024-03-01 at 2b67f6e668)
+ read_ref_at(): special-case ref@{0} for an empty reflog
+ get_oid_basic(): special-case ref@{n} for oldest reflog entry
+ Revert "refs: allow @{n} to work with n-sized reflog"
Originally merged to 'next' on 2024-02-27
The logic to access reflog entries by date and number had ugly
corner cases at the boundaries, which have been cleaned up.
source: <20240226100010.GA1214708@coredump.intra.peff.net>
* jk/textconv-cache-outside-repo-fix (2024-02-26) 1 commit
(merged to 'next' on 2024-03-01 at 8508b83758)
+ userdiff: skip textconv caching when not in a repository
Originally merged to 'next' on 2024-02-26
The code incorrectly attempted to use textconv cache when asked,
even when we are not running in a repository, which has been
corrected.
source: <20240226102729.GB2685773@coredump.intra.peff.net>
* jk/upload-pack-bounded-resources (2024-02-28) 9 commits
(merged to 'next' on 2024-03-01 at b70b6f0913)
+ upload-pack: free tree buffers after parsing
+ upload-pack: use PARSE_OBJECT_SKIP_HASH_CHECK in more places
+ upload-pack: always turn off save_commit_buffer
+ upload-pack: disallow object-info capability by default
+ upload-pack: accept only a single packfile-uri line
+ upload-pack: use a strmap for want-ref lines
+ upload-pack: use oidset for deepen_not list
+ upload-pack: switch deepen-not list to an oid_array
+ upload-pack: drop separate v2 "haves" array
Originally merged to 'next' on 2024-02-29
Various parts of upload-pack has been updated to bound the resource
consumption relative to the size of the repository to protect from
abusive clients.
source: <20240228223700.GA1157826@coredump.intra.peff.net>
* jk/upload-pack-v2-capability-cleanup (2024-02-29) 4 commits
(merged to 'next' on 2024-03-01 at 2750893db7)
+ upload-pack: only accept packfile-uris if we advertised it
+ upload-pack: use existing config mechanism for advertisement
+ upload-pack: centralize setup of sideband-all config
+ upload-pack: use repository struct to get config
Originally merged to 'next' on 2024-02-29
The upload-pack program, when talking over v2, accepted the
packfile-uris protocol extension from the client, even if it did
not advertise the capability, which has been corrected.
source: <20240228224625.GA1158651@coredump.intra.peff.net>
* js/merge-tree-3-trees (2024-02-23) 7 commits
(merged to 'next' on 2024-03-01 at a75dc95f04)
+ fill_tree_descriptor(): mark error message for translation
+ cache-tree: avoid an unnecessary check
+ Always check `parse_tree*()`'s return value
+ t4301: verify that merge-tree fails on missing blob objects
+ merge-ort: do check `parse_tree()`'s return value
+ merge-tree: fail with a non-zero exit code on missing tree objects
+ merge-tree: accept 3 trees as arguments
Originally merged to 'next' on 2024-02-28
"git merge-tree" has learned that the three trees involved in the
3-way merge only need to be trees, not necessarily commits.
source: <pull.1647.git.1706277694231.gitgitgadget@gmail.com>
source: <pull.1651.v4.git.1708677266.gitgitgadget@gmail.com>
* js/remove-cruft-files (2024-02-26) 1 commit
(merged to 'next' on 2024-03-01 at 63100a274b)
+ neue: remove a bogus empty file
Originally merged to 'next' on 2024-02-26
Remove an empty file that shouldn't have been added in the first
place.
source: <pull.1674.git.1708958183225.gitgitgadget@gmail.com>
* jt/commit-redundant-scissors-fix (2024-02-27) 2 commits
(merged to 'next' on 2024-03-01 at e5983498f1)
+ commit: unify logic to avoid multiple scissors lines when merging
+ commit: avoid redundant scissor line with --cleanup=scissors -v
Originally merged to 'next' on 2024-02-29
"git commit -v --cleanup=scissors" used to add the scissors line
twice in the log message buffer, which has been corrected.
source: <Zd2eLxPelxvP8FDk@localhost>
* kn/for-all-refs (2024-02-23) 6 commits
(merged to 'next' on 2024-03-01 at 76a1297ace)
+ for-each-ref: add new option to include root refs
+ ref-filter: rename 'FILTER_REFS_ALL' to 'FILTER_REFS_REGULAR'
+ refs: introduce `refs_for_each_include_root_refs()`
+ refs: extract out `loose_fill_ref_dir_regular_file()`
+ refs: introduce `is_pseudoref()` and `is_headref()`
+ Merge branch 'ps/reftable-backend' into kn/for-all-refs
Originally merged to 'next' on 2024-02-27
"git for-each-ref" learned "--include-root-refs" option to show
even the stuff outside the 'refs/' hierarchy.
source: <20240223100112.44127-1-karthik.188@gmail.com>
* ml/log-merge-with-cherry-pick-and-other-pseudo-heads (2024-02-28) 2 commits
(merged to 'next' on 2024-03-01 at 339111ec08)
+ revision: implement `git log --merge` also for rebase/cherry-pick/revert
+ revision: ensure MERGE_HEAD is a ref in prepare_show_merge
Originally merged to 'next' on 2024-02-29
"git log --merge" learned to pay attention to CHERRY_PICK_HEAD and
other kinds of *_HEAD pseudorefs.
source: <20240228-ml-log-merge-with-cherry-pick-and-other-pseudo-heads-v6-0-8ec34c052b39@gmail.com>
* pb/ort-make-submodule-conflict-message-an-advice (2024-02-26) 1 commit
(merged to 'next' on 2024-03-01 at df880cde2e)
+ merge-ort: turn submodule conflict suggestions into an advice
Originally merged to 'next' on 2024-02-27
When a merge conflicted at a submodule, merge-ort backend used to
unconditionally give a lengthy message to suggest how to resolve
it. Now the message can be squelched as an advice message.
source: <pull.1661.v2.git.git.1708954048301.gitgitgadget@gmail.com>
* ps/reftable-repo-init-fix (2024-02-27) 2 commits
(merged to 'next' on 2024-03-01 at abbf85051b)
+ refs/reftable: don't fail empty transactions in repo without HEAD
+ Merge branch 'ps/remote-helper-repo-initialization-fix' into ps/reftable-repo-init-fix
(this branch uses ps/remote-helper-repo-initialization-fix.)
Originally merged to 'next' on 2024-02-29
Clear the fallout from a fix for 2.44 regression.
source: <95be968e10bd02c64448786e690bbefe5c082577.1709041721.git.ps@pks.im>
* ps/remote-helper-repo-initialization-fix (2024-02-27) 1 commit
(merged to 'next' on 2024-03-01 at 7b79ffbd8f)
+ builtin/clone: allow remote helpers to detect repo
(this branch is used by ps/reftable-repo-init-fix.)
Originally merged to 'next' on 2024-02-29
A custom remote helper no longer cannot access the newly created
repository during "git clone", which is a regression in Git 2.44.
This has been corrected.
source: <9d888adf92e9a8af7c18847219f97d3e595e3e36.1709041721.git.ps@pks.im>
* rs/fetch-simplify-with-starts-with (2024-02-26) 1 commit
(merged to 'next' on 2024-03-01 at 000e015fff)
+ fetch: convert strncmp() with strlen() to starts_with()
Originally merged to 'next' on 2024-02-27
Code simplification.
source: <cb94b938-03f9-4dd3-84c1-f5244ca81be3@web.de>
* rs/name-rev-with-mempool (2024-02-26) 2 commits
(merged to 'next' on 2024-03-01 at d53eac1836)
+ name-rev: use mem_pool_strfmt()
+ mem-pool: add mem_pool_strfmt()
Originally merged to 'next' on 2024-02-27
Many small allocations "git name-rev" makes have been updated to
allocate from a mem-pool.
source: <20240225113947.89357-1-l.s.r@web.de>
* rs/submodule-prefix-simplify (2024-02-26) 1 commit
(merged to 'next' on 2024-03-01 at 05d4d90201)
+ submodule: use strvec_pushf() for --submodule-prefix
Originally merged to 'next' on 2024-02-27
Code simplification.
source: <8cd983fb-32b9-41c6-a9e7-a485b190488c@web.de>
* sg/upload-pack-error-message-fix (2024-02-26) 1 commit
(merged to 'next' on 2024-03-01 at b94664a7a0)
+ upload-pack: don't send null character in abort message to the client
Originally merged to 'next' on 2024-02-27
An error message from "git upload-pack", which responds to "git
fetch" requests, had a trialing NUL in it, which has been
corrected.
source: <20240225183452.1939334-1-szeder.dev@gmail.com>
--------------------------------------------------
[New Topics]
* ag/t0010-modernize (2024-03-05) 1 commit
(merged to 'next' on 2024-03-07 at 38339abc2d)
+ tests: modernize the test script t0010-racy-git.sh
GSoC practice to modernize a test script.
Will merge to 'master'.
source: <pull.1675.v3.git.1709676557639.gitgitgadget@gmail.com>
* fs/find-end-of-log-message-fix (2024-03-07) 1 commit
- wt-status: don't find scissors line beyond buf len
The code to find the effective end of log message can fall into an
endless loop, which has been corrected.
Waiting for review response.
source: <20240307183743.219951-1-flosch@nutanix.com>
* hd/config-mak-os390 (2024-03-06) 1 commit
(merged to 'next' on 2024-03-07 at 289d3ab691)
+ build: support z/OS (OS/390).
Platform specific tweaks for OS/390 has been added to
config.mak.uname.
Will merge to 'master'.
source: <pull.1663.v4.git.git.1709703857881.gitgitgadget@gmail.com>
* jk/core-comment-string (2024-03-07) 15 commits
- config: allow multi-byte core.commentChar
- environment: drop comment_line_char compatibility macro
- wt-status: drop custom comment-char stringification
- sequencer: handle multi-byte comment characters when writing todo list
- find multi-byte comment chars in unterminated buffers
- find multi-byte comment chars in NUL-terminated strings
- prefer comment_line_str to comment_line_char for printing
- strbuf: accept a comment string for strbuf_add_commented_lines()
- strbuf: accept a comment string for strbuf_commented_addf()
- strbuf: accept a comment string for strbuf_stripspace()
- environment: store comment_line_char as a string
- strbuf: avoid shadowing global comment_line_char name
- commit: refactor base-case of adjust_comment_line_char()
- strbuf: avoid static variables in strbuf_add_commented_lines()
- strbuf: simplify comment-handling in add_lines() helper
core.commentChar used to be limited to a single byte, but has been
updated to allow an arbitrary multi-byte sequence.
Will merge to 'next'?
source: <20240307091407.GA2072522@coredump.intra.peff.net>
* jk/doc-remote-helpers-markup-fix (2024-03-07) 1 commit
- doc/gitremote-helpers: fix missing single-quote
Doc mark-up fix.
Will merge to 'next'.
source: <20240307084313.GA2072022@coredump.intra.peff.net>
* js/build-fuzz-more-often (2024-03-05) 3 commits
- SQUASH???
- fuzz: link fuzz programs with `make all` on Linux
- ci: also define CXX environment variable
In addition to building the objects needed, try to link the objects
that are used in fuzzer tests, to make sure at least they build
without bitrot, in Linux CI runs.
Comments?
source: <cover.1709673020.git.steadmon@google.com>
* kh/branch-ref-syntax-advice (2024-03-05) 5 commits
(merged to 'next' on 2024-03-07 at 914f01967b)
+ branch: advise about ref syntax rules
+ advice: use double quotes for regular quoting
+ advice: use backticks for verbatim
+ advice: make all entries stylistically consistent
+ t3200: improve test style
When git refuses to create a branch because the proposed branch
name is not a valid refname, an advice message is given to refer
the user to exact naming rules.
Will merge to 'master'.
source: <cover.1709670287.git.code@khaugsbakk.name>
* kh/doc-commentchar-is-a-byte (2024-03-05) 1 commit
(merged to 'next' on 2024-03-06 at 5941655c04)
+ config: document `core.commentChar` as ASCII-only
The "core.commentChar" configuration variable only allows an ASCII
character, which was not clearly documented, which has been
corrected.
Will merge to 'master'.
source: <9633f9be5ddd9ab3df4b79ee934e1ed47e90bd1d.1709656683.git.code@khaugsbakk.name>
* ps/reftable-block-search-fix (2024-03-07) 2 commits
- reftable/block: fix binary search over restart counter
- reftable/record: fix memory leak when decoding object records
The reftable code has its own custom binary search function whose
comparison callback has an unusual interface, which caused the
binary search to degenerate into a linear search, which has been
corrected.
Will merge to 'next'?
source: <cover.1709843663.git.ps@pks.im>
* ps/reftable-reflog-iteration-perf (2024-03-05) 8 commits
- refs/reftable: track last log record name via strbuf
- reftable/record: use scratch buffer when decoding records
- reftable/record: reuse message when decoding log records
- reftable/record: reuse refnames when decoding log records
- reftable/record: avoid copying author info
- reftable/record: convert old and new object IDs to arrays
- refs/reftable: reload correct stack when creating reflog iter
- Merge branch 'ps/reftable-iteration-perf-part2' into ps/reftable-reflog-iteration-perf
(this branch uses ps/reftable-iteration-perf-part2.)
The code to iterate over reflogs in the reftable has been optimized
to reduce memory allocation and deallocation.
Needs review.
source: <cover.1709640322.git.ps@pks.im>
* sj/userdiff-c-sharp (2024-03-06) 1 commit
- userdiff: better method/property matching for C#
The userdiff patterns for C# has been updated.
Needs review.
source: <pull.1682.v2.git.git.1709756493673.gitgitgadget@gmail.com>
--------------------------------------------------
[Cooking]
* es/config-doc-sort-sections (2024-02-29) 1 commit
(merged to 'next' on 2024-03-04 at 0752144ed7)
+ docs: sort configuration variable groupings alphabetically
Doc updates.
Will merge to 'master'.
source: <20240229190229.20222-1-ericsunshine@charter.net>
* kh/doc-dashed-commands-have-not-worked-for-a-long-time (2024-03-01) 1 commit
(merged to 'next' on 2024-03-04 at 7e070c67f9)
+ gitcli: drop mention of “non-dashed form”
Doc update.
Will merge to 'master'.
source: <5b34bc4e22816f7f19bd26c15a08fe4c749b72f8.1709316230.git.code@khaugsbakk.name>
* jc/xwrite-cleanup (2024-03-02) 3 commits
(merged to 'next' on 2024-03-07 at 43e66f7e4d)
+ repack: check error writing to pack-objects subprocess
+ sideband: avoid short write(2)
+ unpack: replace xwrite() loop with write_in_full()
Uses of xwrite() helper have been audited and updated for better
error checking and simpler code.
Will merge to 'master'.
source: <20240302190348.3946569-1-gitster@pobox.com>
* jc/test-i18ngrep (2024-03-02) 1 commit
(merged to 'next' on 2024-03-06 at 2c57ebc706)
+ test_i18ngrep: hard deprecate and forbid its use
With release 2.44 we got rid of all uses of test_i18ngrep and there
is no in-flight topic that adds a new use of it. Make a call to
test_i18ngrep a hard failure, so that we can remove it at the end
of this release cycle.
Will merge to 'master'.
source: <xmqq5xy4zhdc.fsf@gitster.g>
* gt/core-bare-in-templates (2024-03-04) 1 commit
(merged to 'next' on 2024-03-06 at e54ac5acf9)
+ setup: remove unnecessary variable
Code simplification.
Will merge to 'master'.
source: <20240304151811.511780-1-shyamthakkar001@gmail.com>
* so/clean-dry-run-without-force (2024-03-04) 2 commits
(merged to 'next' on 2024-03-06 at ccf2e123be)
+ clean: further clean-up of implementation around "--force"
+ clean: improve -n and -f implementation and documentation
The implementation in "git clean" that makes "-n" and "-i" ignore
clean.requireForce has been simplified, together with the
documentation.
Will merge to 'master'.
source: <87le6ziqzb.fsf_-_@osv.gnss.ru>
source: <20240303220600.2491792-1-gitster@pobox.com>
* jh/trace2-missing-def-param-fix (2024-03-07) 3 commits
- trace2: emit 'def_param' set with 'cmd_name' event
- trace2: avoid emitting 'def_param' set more than once
- t0211: demonstrate missing 'def_param' events for certain commands
Some trace2 events that lacked def_param have learned to show it,
enriching the output.
Reviewed-by: Josh Steadmon <steadmon@google.com>
cf. <ZejkVOVQBZhLVfHW@google.com>
Will merge to 'next'.
source: <pull.1679.v2.git.1709824949.gitgitgadget@gmail.com>
* ps/reftable-stack-tempfile (2024-03-07) 4 commits
- reftable/stack: register compacted tables as tempfiles
- reftable/stack: register lockfiles during compaction
- reftable/stack: register new tables as tempfiles
- lockfile: report when rollback fails
The code in reftable backend that creates new table files works
better with the tempfile framework to avoid leaving cruft after a
failure.
Will merge to 'next'?
source: <cover.1709816483.git.ps@pks.im>
* rs/opt-parse-long-fixups (2024-03-03) 6 commits
- parse-options: rearrange long_name matching code
- parse-options: normalize arg and long_name before comparison
- parse-options: detect ambiguous self-negation
- parse-options: factor out register_abbrev() and struct parsed_option
- parse-options: set arg of abbreviated option lazily
- parse-options: recognize abbreviated negated option with arg
The parse-options code that deals with abbreviated long option
names have been cleaned up.
Needs review.
source: <20240303121944.20627-1-l.s.r@web.de>
* sj/t9117-path-is-file (2024-03-04) 1 commit
(merged to 'next' on 2024-03-04 at de5f6a74cb)
+ t9117: prefer test_path_* helper functions
GSoC practice to replace "test -f" with "test_path_is_file".
Will merge to 'master'.
source: <20240304095436.56399-2-shejialuo@gmail.com>
* vm/t7301-use-test-path-helpers (2024-03-06) 1 commit
(merged to 'next' on 2024-03-07 at e638654635)
+ t7301: use test_path_is_(missing|file)
GSoC practice to replace "test -f" with "test_path_is_file".
Will merge to 'master'.
source: <20240304171732.64457-2-vincenzo.mezzela@gmail.com>
* cw/git-std-lib (2024-02-28) 4 commits
. SQUASH??? get rid of apparent debugging crufts
. test-stdlib: show that git-std-lib is independent
. git-std-lib: introduce Git Standard Library
. pager: include stdint.h because uintmax_t is used
Split libgit.a out to a separate git-std-lib tor easier reuse.
Expecting a reroll.
source: <cover.1696021277.git.jonathantanmy@google.com>
* js/merge-base-with-missing-commit (2024-02-29) 11 commits
(merged to 'next' on 2024-03-01 at 3e3eabaee9)
+ commit-reach(repo_get_merge_bases_many_dirty): pass on errors
+ commit-reach(repo_get_merge_bases_many): pass on "missing commits" errors
+ commit-reach(get_octopus_merge_bases): pass on "missing commits" errors
+ commit-reach(repo_get_merge_bases): pass on "missing commits" errors
+ commit-reach(get_merge_bases_many_0): pass on "missing commits" errors
+ commit-reach(merge_bases_many): pass on "missing commits" errors
+ commit-reach(paint_down_to_common): start reporting errors
+ commit-reach(paint_down_to_common): prepare for handling shallow commits
+ commit-reach(repo_in_merge_bases_many): report missing commits
+ commit-reach(repo_in_merge_bases_many): optionally expect missing commits
+ commit-reach(paint_down_to_common): plug two memory leaks
Originally merged to 'next' on 2024-02-29
Make sure failure return from merge_bases_many() is properly caught.
Needs an incremental fix-up.
cf.<20240301065805.GB2680308@coredump.intra.peff.net>
source: <pull.1657.v4.git.1709113457.gitgitgadget@gmail.com>
* rj/complete-worktree-paths-fix (2024-02-27) 1 commit
(merged to 'next' on 2024-03-06 at b6ba949383)
+ completion: fix __git_complete_worktree_paths
The logic to complete the command line arguments to "git worktree"
subcommand (in contrib/) has been updated to correctly honor things
like "git -C dir" etc.
Will merge to 'master'.
source: <b8f09e20-d0d3-4e0b-afe2-31affeb61052@gmail.com>
* rs/t-ctype-simplify (2024-03-03) 4 commits
(merged to 'next' on 2024-03-04 at 9bd84a8877)
+ t-ctype: avoid duplicating class names
+ t-ctype: align output of i
+ t-ctype: simplify EOF check
+ t-ctype: allow NUL anywhere in the specification string
Code simplification to one unit-test program.
Will merge to 'master'.
source: <20240303101330.20187-1-l.s.r@web.de>
* pw/rebase-i-ignore-cherry-pick-help-environment (2024-02-27) 1 commit
- rebase -i: stop setting GIT_CHERRY_PICK_HELP
Code simplification by getting rid of code that sets an environment
variable that is no longer used.
Will merge to 'next'.
source: <pull.1678.git.1709042783847.gitgitgadget@gmail.com>
* as/option-names-in-messages (2024-03-05) 4 commits
(merged to 'next' on 2024-03-07 at 73ab51faba)
+ revision.c: trivial fix to message
+ builtin/clone.c: trivial fix of message
+ builtin/remote.c: trivial fix of error message
+ transport-helper.c: trivial fix of error message
Error message updates.
Will merge to 'master'.
source: <20240216101647.28837-1-ash@kambanaria.org>
* jh/fsmonitor-icase-corner-case-fix (2024-03-06) 14 commits
(merged to 'next' on 2024-03-06 at 356eafea7e)
+ fsmonitor: support case-insensitive events
+ fsmonitor: refactor bit invalidation in refresh callback
+ fsmonitor: trace the new invalidated cache-entry count
+ fsmonitor: return invalidated cache-entry count on non-directory event
+ fsmonitor: remove custom loop from non-directory path handler
+ fsmonitor: return invalidated cache-entry count on directory event
+ fsmonitor: move untracked-cache invalidation into helper functions
+ fsmonitor: refactor untracked-cache invalidation
+ dir: create untracked_cache_invalidate_trimmed_path()
+ fsmonitor: refactor refresh callback for non-directory events
+ fsmonitor: clarify handling of directory events in callback helper
+ fsmonitor: refactor refresh callback on directory events
+ t7527: add case-insensitve test for FSMonitor
+ name-hash: add index_dir_find()
FSMonitor client code was confused when FSEvents were given in a
different case on a case-insensitive filesystem, which has been
corrected.
Acked-by: Patrick Steinhardt <ps@pks.im>
cf. <ZehofMaSZyUq8S1N@tanuki>
Will merge to 'master'.
source: <pull.1662.v3.git.1708983565.gitgitgadget@gmail.com>
* ps/reftable-iteration-perf-part2 (2024-03-04) 13 commits
(merged to 'next' on 2024-03-06 at e8ba314585)
+ refs/reftable: precompute prefix length
+ reftable: allow inlining of a few functions
+ reftable/record: decode keys in place
+ reftable/record: reuse refname when copying
+ reftable/record: reuse refname when decoding
+ reftable/merged: avoid duplicate pqueue emptiness check
+ reftable/merged: circumvent pqueue with single subiter
+ reftable/merged: handle subiter cleanup on close only
+ reftable/merged: remove unnecessary null check for subiters
+ reftable/merged: make subiters own their records
+ reftable/merged: advance subiter on subsequent iteration
+ reftable/merged: make `merged_iter` structure private
+ reftable/pq: use `size_t` to track iterator index
(this branch is used by ps/reftable-reflog-iteration-perf.)
The code to iterate over refs with the reftable backend has seen
some optimization.
Will merge to 'master'.
source: <cover.1709548907.git.ps@pks.im>
* js/cmake-with-test-tool (2024-02-23) 2 commits
- cmake: let `test-tool` run the unit tests, too
- Merge branch 'js/unit-test-suite-runner' into js/cmake-with-test-tool
(this branch uses js/unit-test-suite-runner.)
"test-tool" is now built in CMake build to also run the unit tests.
May want to roll it into the base topic.
source: <pull.1666.git.1708038924522.gitgitgadget@gmail.com>
* js/unit-test-suite-runner (2024-02-23) 8 commits
- ci: use test-tool as unit test runner on Windows
- t/Makefile: run unit tests alongside shell tests
- unit tests: add rule for running with test-tool
- test-tool run-command testsuite: support unit tests
- test-tool run-command testsuite: remove hardcoded filter
- test-tool run-command testsuite: get shell from env
- t0080: turn t-basic unit test into a helper
- Merge branch 'jk/unit-tests-buildfix' into js/unit-test-suite-runner
(this branch is used by js/cmake-with-test-tool.)
The "test-tool" has been taught to run testsuite tests in parallel,
bypassing the need to use the "prove" tool.
Needs review.
source: <cover.1708728717.git.steadmon@google.com>
* rj/complete-reflog (2024-03-03) 5 commits
(merged to 'next' on 2024-03-06 at 0f1a25debc)
+ completion: reflog subcommands and options
+ completion: factor out __git_resolve_builtins
+ completion: introduce __git_find_subcommand
+ completion: reflog show <log-options>
+ completion: reflog with implicit "show"
The command line completion script (in contrib/) learned to
complete "git reflog" better.
Will merge to 'master'.
source: <ea6c8890-9ff3-46c9-b933-6a52083b1001@gmail.com>
* bk/complete-dirname-for-am-and-format-patch (2024-01-12) 1 commit
- completion: dir-type optargs for am, format-patch
Command line completion support (in contrib/) has been
updated for a few commands to complete directory names where a
directory name is expected.
Expecting a reroll.
cf. <40c3a824-a961-490b-94d4-4eb23c8f713d@gmail.com>
cf. <6683f24e-7e56-489d-be2d-8afe1fc38d2b@gmail.com>
source: <d37781c3-6af2-409b-95a8-660a9b92d20b@smtp-relay.sendinblue.com>
* bk/complete-send-email (2024-01-12) 1 commit
- completion: don't complete revs when --no-format-patch
Command line completion support (in contrib/) has been taught to
avoid offering revision names as candidates to "git send-email" when
the command is used to send pre-generated files.
Expecting a reroll.
cf. <CAC4O8c88Z3ZqxH2VVaNPpEGB3moL5dJcg3cOWuLWwQ_hLrJMtA@mail.gmail.com>
source: <a718b5ee-afb0-44bd-a299-3208fac43506@smtp-relay.sendinblue.com>
* la/trailer-api (2024-03-01) 9 commits
(merged to 'next' on 2024-03-06 at f119923ff6)
+ format_trailers_from_commit(): indirectly call trailer_info_get()
+ format_trailer_info(): move "fast path" to caller
+ format_trailers(): use strbuf instead of FILE
+ trailer_info_get(): reorder parameters
+ trailer: move interpret_trailers() to interpret-trailers.c
+ trailer: reorder format_trailers_from_commit() parameters
+ trailer: rename functions to use 'trailer'
+ shortlog: add test for de-duplicating folded trailers
+ trailer: free trailer_info _after_ all related usage
Trailer API updates.
Acked-by: Christian Couder <christian.couder@gmail.com>
cf. <CAP8UFD1Zd+9q0z1JmfOf60S2vn5-sD3SafDvAJUzRFwHJKcb8A@mail.gmail.com>
Will merge to 'master'.
source: <pull.1632.v6.git.1709252086.gitgitgadget@gmail.com>
* tb/path-filter-fix (2024-01-31) 16 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: new Bloom filter version that fixes murmur3
- commit-graph: unconditionally load Bloom filters
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- 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.
Waiting for a final ack?
cf. <ZcFjkfbsBfk7JQIH@nand.local>
source: <cover.1706741516.git.me@ttaylorr.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.
Will merge to and cook in 'next'.
cf. <xmqqv86z5359.fsf@gitster.g>
source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>
* 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>
^ permalink raw reply
* Re: [PATCH 1/1] Documentation/user-manual.txt: example for generating object hashes
From: Dirk Gouders @ 2024-03-08 6:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqil27c5p1.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Dirk Gouders <dirk@gouders.net> writes:
>> +The following is a short example that demonstrates how hashes can be
>> +generated manually:
>> +
>> +Let's asume a small text file with the content "Hello git.\n"
>> +-------------------------------------------------
>> +$ cat > hello.txt <<EOF
>> +Hello git.
>> +EOF
>> +-------------------------------------------------
>> +
>> +We can now manually generate the hash `git` would use for this file:
>> +
>> +- The object we want the hash for is of type "blob" and its size is
>> + 11 bytes.
>> +
>> +- Prepend the object header to the file content and feed this to
>> + sha1sum(1):
>> +
>> +-------------------------------------------------
>> +$ printf "blob 11\0" | cat - hello.txt | sha1sum
>> +7217614ba6e5f4e7db2edaa2cdf5fb5ee4358b57 .
>> +-------------------------------------------------
>> +
>
> ... something like the above (modulo coding style) would be a useful
> addition to help those who want to convince themselves they
> understand how (some parts of) Git works under the hood, and I think
> it would be a welcome addition to some subset of such readers (the
> rest of the world may feel it is way too much detail, though).
May I ask what you meant by "modulo coding style", e.g. where I should
look at to make the code of similar style?
I would also add that git-hash-object(1) could be used to verify the
result if you think that is OK.
In addition to a suggestion in another mail, the commit would
consist of substantial content you suggested and perhaps, you could tell
me how to express this; would a Helped-By be correct?
Dirk
^ permalink raw reply
* Re: [PATCH] wt-status: Don't find scissors line beyond buf len
From: Florian Schmidt @ 2024-03-08 9:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jonathan Davies, Phillip Wood, Denton Liu, Linus Arver
In-Reply-To: <xmqq34t1n91w.fsf@gitster.g>
That's a quick review cycle, thanks!
On 07/03/2024 19:20, Junio C Hamano wrote:
> You do not have to say "Currently, if"; just "If" is sufficient.
> Cf. Documentation/SubmittingPatches[[present-tense]]
ack
> Looks correct, but we probably can make the fix a lot more isolated
> into a single block, like the attached patch. How does this look?
>
> wt-status.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git c/wt-status.c w/wt-status.c
> index b5a29083df..511f37cfe0 100644
> --- c/wt-status.c
> +++ w/wt-status.c
> @@ -1093,8 +1093,11 @@ size_t wt_status_locate_end(const char *s, size_t len)
> strbuf_addf(&pattern, "\n%c %s", comment_line_char, cut_line);
> if (starts_with(s, pattern.buf + 1))
> len = 0;
> - else if ((p = strstr(s, pattern.buf)))
> - len = p - s + 1;
> + else if ((p = strstr(s, pattern.buf))) {
> + int newlen = p - s + 1;
> + if (newlen < len)
> + len = newlen;
> + }
> strbuf_release(&pattern);
> return len;
> }
That looks good to me, thanks! For context, I had sent in the slightly
larger patch because at first look, I got confused by the fact that
wt_status_locate_end takes len as a parameter, but then seemingly
doesn't read it at all and only writes to it. (Of course, if neither the
if nor the if-else branch are hit, len is in fact read when it is
returned unchanged.) So I made the patch a bit larger in the hope that
the next cursory reader might not get confused.
But this option is a much more minimal patch, and functionally the same.
So it comes down to style, and you have a much better feeling for that
in this code base, so I'm happy to go with this.
Do you want me to send this version as a v2 to you + the list as per the
documentation?
Cheers,
flosch
^ permalink raw reply
* Re: [PATCH] wt-status: Don't find scissors line beyond buf len
From: Florian Schmidt @ 2024-03-08 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Davies, Phillip Wood, Denton Liu
In-Reply-To: <xmqqsf11ltrt.fsf@gitster.g>
On 07/03/2024 19:35, Junio C Hamano wrote:
> Florian Schmidt <flosch@nutanix.com> writes:
>
>> Side remark: Since strstr() doesn't consider len, and will always search
>> up to a null byte, I now wonder whether it would be safer to create a
>> new strbuf that only contains the len bytes we want to operate on.
>
> That is a valid concern in general, but does not seem to apply to
> the current codebase. Thanks for being careful.
Thanks, that confirms my cursory look at the consumers of the function.
If you think that it's unlikely that in the future, a new user of this
function would provide a non-terminated string, then there is no need
for action. I guess the aim is to use strbufs wherever suitable in the
first place, anyway, and those won't have this issue?
Cheers,
flosch
^ permalink raw reply
* Support dst-prefix and src-prefix in the .gitconfig file
From: David Heidelberg @ 2024-03-08 9:59 UTC (permalink / raw)
To: git; +Cc: peter.hutterer
Hello,
Recently Peter brought the `src-prefix = ./` and `dst-prefix = ./` as a
possible solution to easy copy-paste of file location without needing to
remove the prefix "[ab]/".
The problem lies in not being able to define these options in .gitconfig
I would love to have the option to do
```
[diff]
src-prefix = ./
dst-prefix = ./
```
It seems to be a much better solution than using the available `noprefix
= true` which breaks multiple workflows.
David
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH 11/15] find multi-byte comment chars in unterminated buffers
From: Phillip Wood @ 2024-03-08 10:17 UTC (permalink / raw)
To: René Scharfe, Jeff King, git
Cc: Junio C Hamano, Dragan Simic, Kristoffer Haugsbakk,
Manlio Perillo
In-Reply-To: <3f823e48-572c-4e19-ab76-e6d7cab9461f@web.de>
Hi Peff and René
On 07/03/2024 19:42, René Scharfe wrote:
> Am 07.03.24 um 10:26 schrieb Jeff King:
>> diff --git a/sequencer.c b/sequencer.c
>> index 991a2dbe96..664986e3b2 100644
>> --- a/sequencer.c
>> +++ b/sequencer.c
>> @@ -1840,7 +1840,7 @@ static int is_fixup_flag(enum todo_command command, unsigned flag)
>> static void add_commented_lines(struct strbuf *buf, const void *str, size_t len)
>> {
>> const char *s = str;
>> - while (len > 0 && s[0] == comment_line_char) {
>> + while (starts_with_mem(s, len, comment_line_str)) {
>> size_t count;
>> const char *n = memchr(s, '\n', len);
>> if (!n)
>> @@ -2562,7 +2562,7 @@ static int parse_insn_line(struct repository *r, struct todo_item *item,
>> /* left-trim */
>> bol += strspn(bol, " \t");
>>
>> - if (bol == eol || *bol == '\r' || *bol == comment_line_char) {
>> + if (bol == eol || *bol == '\r' || starts_with_mem(bol, eol - bol, comment_line_str)) {
>
> If the strspn() call is safe (which it is, as the caller expects the
> string to be NUL-terminated) then you could use starts_with() here and
> avoid the length calculation. But that would also match
> comment_line_str values that contain LF, which the _mem version does not > and that's better.
I agree with your analysis. I do wonder though if we should reject
whitespace and control characters when parsing core.commentChar, it
feels like accepting them is a bug waiting to happen. If
comment_line_char starts with ' ' or '\t' that part will be eaten by the
strspn() above and so starts_with_mem() wont match. Also we will never
match a comment if comment_line_str contains '\n'.
> Not sure why lines that start with CR are considered comment lines,
> though.
I think it is a lazy way of looking for an empty line ending in CR LF,
it should really be
|| (bol[0] == '\r' && bol[1] == '\n') ||
Best Wishes
Phillip
^ permalink raw reply
* Re: [PATCH 12/15] sequencer: handle multi-byte comment characters when writing todo list
From: Phillip Wood @ 2024-03-08 10:20 UTC (permalink / raw)
To: Jeff King, git
Cc: Junio C Hamano, Dragan Simic, Kristoffer Haugsbakk,
Manlio Perillo
In-Reply-To: <20240307092747.GL2080210@coredump.intra.peff.net>
Hi Peff
On 07/03/2024 09:27, Jeff King wrote:
> We already match multi-byte comment characters in parse_insn_line(),
> thanks to the previous commit, yielding a TODO_COMMENT entry. But in
> todo_list_to_strbuf(), we may call command_to_char() to convert that
> back into something we can output.
>
> We can't just return comment_line_char anymore, since it may require
> multiple bytes. Instead, we'll return "0" for this case, which is the
> same thing we'd return for a command which does not have a single-letter
> abbreviation (e.g., "revert" or "noop"). In that case the caller then
> falls back to outputting the full name via command_to_string(). So we
> can handle TODO_COMMENT there, returning the full string.
If you do re-roll it might be helpful to emphasize that there is only
one caller.
> Note that there are many other callers of command_to_string(), which
> will now behave differently if they pass TODO_COMMENT. But we would not
> expect that to happen; prior to this commit, the function just calls
> die() in this case. And looking at those callers, that makes sense;
> e.g., do_pick_commit() will only be called when servicing a pick
> command, and should never be called for a comment in the first place.
I've checked the other callers and agree with your analysis. The fact
that it used to die() also makes it pretty clear that this should be safe.
Best Wishes
Phillip
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> sequencer.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 664986e3b2..9e2851428b 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1779,14 +1779,16 @@ static const char *command_to_string(const enum todo_command command)
> {
> if (command < TODO_COMMENT)
> return todo_command_info[command].str;
> + if (command == TODO_COMMENT)
> + return comment_line_str;
> die(_("unknown command: %d"), command);
> }
>
> static char command_to_char(const enum todo_command command)
> {
> if (command < TODO_COMMENT)
> return todo_command_info[command].c;
> - return comment_line_char;
> + return 0;
> }
>
> static int is_noop(const enum todo_command command)
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2024, #02; Thu, 7)
From: Christian Couder @ 2024-03-08 10:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqplw5ihm7.fsf@gitster.g>
(Sorry for sending this first privately to Junio by mistake.)
On Fri, Mar 8, 2024 at 3:27 AM Junio C Hamano <gitster@pobox.com> wrote:
> * cc/rev-list-allow-missing-tips (2024-02-28) 5 commits
> (merged to 'next' on 2024-03-01 at fd7b109d04)
> + revision: fix --missing=[print|allow*] for annotated tags
> (merged to 'next' on 2024-03-01 at ac0fc94378)
> + rev-list: allow missing tips with --missing=[print|allow*]
> + t6022: fix 'test' style and 'even though' typo
> + oidset: refactor oidset_insert_from_set()
> + revision: clarify a 'return NULL' in get_reference()
>
> Originally merged to 'next' on 2024-02-28
>
> "git rev-list --missing=print" has learned to optionally take
> "--allow-missing-tips", which allows the objects at the starting
> points to be missing.
The description might want to be updated as no new
"--allow-missing-tips" option is introduced anymore. Maybe something
like this instead:
"git rev-list --missing=[print|allow*]" has learned to not die when
some tips passed to it as command line arguments are missing. Instead
those tips are just reported among the missing objects and ignored for
traversal.
> source: <20240214142513.4002639-1-christian.couder@gmail.com>
^ permalink raw reply
* Re: [PATCH 0/15] allow multi-byte core.commentChar
From: Phillip Wood @ 2024-03-08 11:07 UTC (permalink / raw)
To: Jeff King, git
Cc: Junio C Hamano, Dragan Simic, Kristoffer Haugsbakk,
Manlio Perillo
In-Reply-To: <20240307091407.GA2072522@coredump.intra.peff.net>
Hi Peff
On 07/03/2024 09:14, Jeff King wrote:
> On Wed, Mar 06, 2024 at 03:08:04AM -0500, Jeff King wrote:
>
>> For a more readable series, I'd guess it would make sense to introduce
>> comment_line_str as a separate variable (but continue to enforce the
>> single-char rule), convert the easy cases en masse, the tricky cases one
>> by one, and then finally drop comment_line_char entirely. At which point
>> the config rules can be lifted to allow multi-byte strings.
>
> I ended up cleaning this up. Like I said, this isn't something I'm
> personally that interested in. But it just seemed like a wart that this
> one spot could not handle multi-byte characters that all the cool kids
> are using in their prompts etc these days.
I agree it would be nice to support multibyte comment characters on
principle even if I don't think I'd use that feature myself. I've looked
through the changes to the sequencer and they all look sensible to me.
As I mentioned when looking at patch 11 I do wonder if we want to reject
ascii whitespace and control characters when parsing core.commentChar.
At a minimum leading whitespace and LF anywhere in the comment string
feel like they are asking for trouble.
Best Wishes
Phillip
> Plus it was kind of an interesting puzzle for how to lay out the
> refactoring to make each step self-consistent. At the very least, I
> think the first couple of cleanups are worth it even if we do not see
> the whole thing through. ;)
>
> It obviously nullifies kh/doc-commentchar-is-a-byte, which is in 'next'.
> Sadly "git merge" does not find a conflict with the documentation update
> in patch 15, so we'll have to remember to pick up one topic or the
> other.
>
> I'm using U+00BB as my commentChar for now to see if any bugs show up,
> but I expect I'll get sick of it after a few days.
>
> [01/15]: strbuf: simplify comment-handling in add_lines() helper
> [02/15]: strbuf: avoid static variables in strbuf_add_commented_lines()
> [03/15]: commit: refactor base-case of adjust_comment_line_char()
> [04/15]: strbuf: avoid shadowing global comment_line_char name
>
> These four are cleanups that could be taken independently.
>
> [05/15]: environment: store comment_line_char as a string
>
> This one preps us for incrementally moving code over to the new
> system.
>
> [06/15]: strbuf: accept a comment string for strbuf_stripspace()
> [07/15]: strbuf: accept a comment string for strbuf_commented_addf()
> [08/15]: strbuf: accept a comment string for strbuf_add_commented_lines()
> [09/15]: prefer comment_line_str to comment_line_char for printing
> [10/15]: find multi-byte comment chars in NUL-terminated strings
> [11/15]: find multi-byte comment chars in unterminated buffers
> [12/15]: sequencer: handle multi-byte comment characters when writing todo list
> [13/15]: wt-status: drop custom comment-char stringification
>
> These ones are the actual transition.
>
> [14/15]: environment: drop comment_line_char compatibility macro
> [15/15]: config: allow multi-byte core.commentChar
>
> And then we tie it off by dropping the now-unused bits and loosening
> the config logic.
>
> Documentation/config/core.txt | 4 ++-
> add-patch.c | 14 +++++-----
> builtin/branch.c | 8 +++---
> builtin/commit.c | 19 +++++++-------
> builtin/merge.c | 12 ++++-----
> builtin/notes.c | 10 ++++----
> builtin/rebase.c | 2 +-
> builtin/stripspace.c | 4 +--
> builtin/tag.c | 14 +++++-----
> commit.c | 3 ++-
> config.c | 6 ++---
> environment.c | 2 +-
> environment.h | 2 +-
> fmt-merge-msg.c | 8 +++---
> rebase-interactive.c | 10 ++++----
> sequencer.c | 48 ++++++++++++++++++-----------------
> strbuf.c | 47 ++++++++++++++++++----------------
> strbuf.h | 9 ++++---
> t/t0030-stripspace.sh | 5 ++++
> t/t7507-commit-verbose.sh | 10 ++++++++
> t/t7508-status.sh | 4 ++-
> trailer.c | 6 ++---
> wt-status.c | 31 +++++++++-------------
> 23 files changed, 149 insertions(+), 129 deletions(-)
>
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2024, #02; Thu, 7)
From: Phillip Wood @ 2024-03-08 13:56 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <xmqqplw5ihm7.fsf@gitster.g>
On 08/03/2024 02:26, Junio C Hamano wrote:
> * rs/t-ctype-simplify (2024-03-03) 4 commits
> (merged to 'next' on 2024-03-04 at 9bd84a8877)
> + t-ctype: avoid duplicating class names
> + t-ctype: align output of i
> + t-ctype: simplify EOF check
> + t-ctype: allow NUL anywhere in the specification string
>
> Code simplification to one unit-test program.
>
> Will merge to 'master'.
> source: <20240303101330.20187-1-l.s.r@web.de>
I have some concerns about the last patch of this series c.f.
<0947cb09-8b07-4fcd-bbe2-ae37c2cd5ec7@gmail.com> It might be too late
for this series but using the internal implementation functions rather
than TEST() is not a pattern that I would want us to encourage.
Best Wishes
Phillip
^ permalink raw reply
* Re: Accuracy of "git blame -C" - are there configuration options?
From: Baumann, Moritz @ 2024-03-08 13:59 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <AS1PR02MB81858FD5DDD15551754AEA74945E2@AS1PR02MB8185.eurprd02.prod.outlook.com>
Maybe I should rephrase the question to clarify what I want to achieve:
Is there a way to execute 'git blame -C' for an entire large file at
once and get the same accurate results as if 'git blame -C -L' had been
called for each line separately?
---
Hi,
A colleague recently experimented with "git blame -C" and noticed that
the accuracy with which git detects lines moved from other files varies
a lot depending on the sizes of the files involved.
Example repository: https://github.com/Boddlnagg/git-blame-problem
The latest commit on all branches moves some lines from Decl.cpp to
line 93 of DeclBase.cpp. "git blame -C" doesn't detect this on main, but
on the "works-as-expected" branch, in which the size of Decl.cpp was
artificially reduced, it does.
Further experiments show that the following work as well:
git blame -L 93,95 -C main -- DeclBase.cpp
git blame -L 80,108 -C main -- DeclBase.cpp
However, with a sufficiently large range, it stops working again:
git blame -L 80,109 -C main -- DeclBase.cpp
How does the pickaxe search of git blame work under the hood? Are there
any configuration options I can use if I want to trade performance for
accuracy?
Best regards,
Moritz Baumann
^ permalink raw reply
* Re: [PATCH v2 4/4] t-ctype: avoid duplicating class names
From: Phillip Wood @ 2024-03-08 14:05 UTC (permalink / raw)
To: René Scharfe, phillip.wood, git
Cc: Josh Steadmon, Achu Luma, Christian Couder
In-Reply-To: <3ef0927f-4d7b-4061-925e-c113d1c8730d@web.de>
On 06/03/2024 18:16, René Scharfe wrote:
Sorry for the delay I somehow missed your reply
> Hello Phillip,
>
> Am 04.03.24 um 10:51 schrieb Phillip Wood:
>> On 03/03/2024 10:13, René Scharfe wrote:
>>> TEST_CTYPE_FUNC defines a function for testing a character classifier,
>>> TEST_CHAR_CLASS calls it, causing the class name to be mentioned twice.
>>>
>>> Avoid the need to define a class-specific function by letting
>>> TEST_CHAR_CLASS do all the work. This is done by using the internal
>>> functions test__run_begin() and test__run_end(), but they do exist to be
>>> used in test macros after all.
>>
>> Those internal functions exist to implement the TEST() macro, they
>> are not really intended for use outside that (which is why they are
>> marked as private in the header file). If we ever want to update the
>> implementation of TEST() it will be a lot harder if we're using the
>> internal implementation directly in test files. Unit tests should be
>> wrapping TEST() if it is appropriate but not the internal
>> implementation directly.
>
> forcing tests to be expressions and not allow them to use statements is
> an unusual requirement.
I don't think it is that unusual to require tests to be implemented as
functions which more or less amounts to the same thing.
> I don't see how the added friction would make
> tests any better. It just requires more boilerplate code and annoying
> repetition. What kind of changes do you envision that would be
> hindered by allowing statements?
I'm worried about bugs being introduced by the internal functions being
used incorrectly - it is not a user friendly API because it is designed
around the limitations of implementing TEST(), not for general
consumption. The unit test framework is very new so I don't think we can
be sure that we wont need to change it and that will be more difficult
if unit tests do not use TEST(). Maybe one of the changes we need is a
better way of allowing statements?
>> Ideally we wouldn't need TEST_CTYPE_FUNC as there would only be a
>> single function that was passed a ctype predicate, an input array and
>> an array of expected results. Unfortunately I don't think that is
>> possible due the the way the ctype predicates are implemented. Having
>> separate macros to define the test function and to run the test is
>> annoying but I don't think it is really worth exposing the internal
>> implementation just to avoid it.
>
> The classifiers are currently implemented as macros. We could turn them
> into inline functions and would then be able to pass them to a test
> function. Improving testability is a good idea, but also somehow feels
> like the tail wagging the dog. It would be easy, though, I think. And
> less gross than:
Making them functions would allow them to be passed as function
arguments in our code as well, though I don't know if we have much use
for that. I certainly agree it would be better than the alternative below.
Best Wishes
Phillip
>>> Alternatively we could unroll the loop to provide a very long expression
>>> that tests all 256 characters and EOF and hand that to TEST, but that
>>> seems awkward and hard to read.
>
> ... which would yield unsightly test macros and huge test binaries. But
> it would certainly be possible, and keep the definitions of the actual
> tests clean.
>
> René
>
^ permalink raw reply
* [PATCH 0/4] checkout: cleanup --conflict=
From: Phillip Wood via GitGitGadget @ 2024-03-08 14:14 UTC (permalink / raw)
To: git; +Cc: Phillip Wood
Phillip Wood (4):
xdiff-interface: refactor parsing of merge.conflictstyle
merge-ll: introduce LL_MERGE_OPTIONS_INIT
merge options: add a conflict style member
checkout: cleanup --conflict=<style> parsing
builtin/checkout.c | 40 +++++++++++++++++++++-------------------
merge-ll.c | 6 ++++--
merge-ll.h | 5 +++++
merge-ort.c | 3 ++-
merge-recursive.c | 5 ++++-
merge-recursive.h | 1 +
t/t7201-co.sh | 6 ++++++
xdiff-interface.c | 29 ++++++++++++++++++-----------
xdiff-interface.h | 1 +
9 files changed, 62 insertions(+), 34 deletions(-)
base-commit: b387623c12f3f4a376e4d35a610fd3e55d7ea907
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1684%2Fphillipwood%2Frefactor-conflict-style-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1684/phillipwood/refactor-conflict-style-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1684
--
gitgitgadget
^ permalink raw reply
* [PATCH 1/4] xdiff-interface: refactor parsing of merge.conflictstyle
From: Phillip Wood via GitGitGadget @ 2024-03-08 14:14 UTC (permalink / raw)
To: git; +Cc: Phillip Wood, Phillip Wood
In-Reply-To: <pull.1684.git.1709907270.gitgitgadget@gmail.com>
From: Phillip Wood <phillip.wood@dunelm.org.uk>
Factor out the code that parses of conflict style name so it can be
reused in a later commit that wants to parse the name given on the
command line.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
---
xdiff-interface.c | 29 ++++++++++++++++++-----------
xdiff-interface.h | 1 +
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 3162f517434..daee3c584e1 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -305,6 +305,22 @@ int xdiff_compare_lines(const char *l1, long s1,
return xdl_recmatch(l1, s1, l2, s2, flags);
}
+int parse_conflict_style(const char *value)
+{
+ if (!strcmp(value, "diff3"))
+ return XDL_MERGE_DIFF3;
+ else if (!strcmp(value, "zdiff3"))
+ return XDL_MERGE_ZEALOUS_DIFF3;
+ else if (!strcmp(value, "merge"))
+ return 0;
+ /*
+ * Please update _git_checkout() in git-completion.bash when
+ * you add new merge config
+ */
+ else
+ return -1;
+}
+
int git_xmerge_style = -1;
int git_xmerge_config(const char *var, const char *value,
@@ -313,17 +329,8 @@ int git_xmerge_config(const char *var, const char *value,
if (!strcmp(var, "merge.conflictstyle")) {
if (!value)
return config_error_nonbool(var);
- if (!strcmp(value, "diff3"))
- git_xmerge_style = XDL_MERGE_DIFF3;
- else if (!strcmp(value, "zdiff3"))
- git_xmerge_style = XDL_MERGE_ZEALOUS_DIFF3;
- else if (!strcmp(value, "merge"))
- git_xmerge_style = 0;
- /*
- * Please update _git_checkout() in
- * git-completion.bash when you add new merge config
- */
- else
+ git_xmerge_style = parse_conflict_style(value);
+ if (git_xmerge_style == -1)
return error(_("unknown style '%s' given for '%s'"),
value, var);
return 0;
diff --git a/xdiff-interface.h b/xdiff-interface.h
index e6f80df0462..c569b7c5203 100644
--- a/xdiff-interface.h
+++ b/xdiff-interface.h
@@ -51,6 +51,7 @@ int buffer_is_binary(const char *ptr, unsigned long size);
void xdiff_set_find_func(xdemitconf_t *xecfg, const char *line, int cflags);
void xdiff_clear_find_func(xdemitconf_t *xecfg);
struct config_context;
+int parse_conflict_style(const char *value);
int git_xmerge_config(const char *var, const char *value,
const struct config_context *ctx, void *cb);
extern int git_xmerge_style;
--
gitgitgadget
^ permalink raw reply related
* [PATCH 2/4] merge-ll: introduce LL_MERGE_OPTIONS_INIT
From: Phillip Wood via GitGitGadget @ 2024-03-08 14:14 UTC (permalink / raw)
To: git; +Cc: Phillip Wood, Phillip Wood
In-Reply-To: <pull.1684.git.1709907270.gitgitgadget@gmail.com>
From: Phillip Wood <phillip.wood@dunelm.org.uk>
Introduce a macro to initialize `struct ll_merge_options` in preparation
for the next commit that will add a new member that needs to be
initialized to a non-zero value.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
---
builtin/checkout.c | 3 +--
merge-ll.c | 2 +-
merge-ll.h | 2 ++
merge-ort.c | 2 +-
merge-recursive.c | 2 +-
5 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 067c2519334..6ded58bd95c 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -262,7 +262,7 @@ static int checkout_merged(int pos, const struct checkout *state,
mmbuffer_t result_buf;
struct object_id threeway[3];
unsigned mode = 0;
- struct ll_merge_options ll_opts;
+ struct ll_merge_options ll_opts = LL_MERGE_OPTIONS_INIT;
int renormalize = 0;
memset(threeway, 0, sizeof(threeway));
@@ -284,7 +284,6 @@ static int checkout_merged(int pos, const struct checkout *state,
read_mmblob(&ours, &threeway[1]);
read_mmblob(&theirs, &threeway[2]);
- memset(&ll_opts, 0, sizeof(ll_opts));
git_config_get_bool("merge.renormalize", &renormalize);
ll_opts.renormalize = renormalize;
merge_status = ll_merge(&result_buf, path, &ancestor, "base",
diff --git a/merge-ll.c b/merge-ll.c
index 61e0ae53981..6570707297d 100644
--- a/merge-ll.c
+++ b/merge-ll.c
@@ -401,7 +401,7 @@ enum ll_merge_result ll_merge(mmbuffer_t *result_buf,
const struct ll_merge_options *opts)
{
struct attr_check *check = load_merge_attributes();
- static const struct ll_merge_options default_opts;
+ static const struct ll_merge_options default_opts = LL_MERGE_OPTIONS_INIT;
const char *ll_driver_name = NULL;
int marker_size = DEFAULT_CONFLICT_MARKER_SIZE;
const struct ll_merge_driver *driver;
diff --git a/merge-ll.h b/merge-ll.h
index e4a20e81a3a..af1ee36abdb 100644
--- a/merge-ll.h
+++ b/merge-ll.h
@@ -82,6 +82,8 @@ struct ll_merge_options {
long xdl_opts;
};
+#define LL_MERGE_OPTIONS_INIT {0}
+
enum ll_merge_result {
LL_MERGE_ERROR = -1,
LL_MERGE_OK = 0,
diff --git a/merge-ort.c b/merge-ort.c
index 8617babee41..4a02c3ecd99 100644
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -1956,7 +1956,7 @@ static int merge_3way(struct merge_options *opt,
mmbuffer_t *result_buf)
{
mmfile_t orig, src1, src2;
- struct ll_merge_options ll_opts = {0};
+ struct ll_merge_options ll_opts = LL_MERGE_OPTIONS_INIT;
char *base, *name1, *name2;
enum ll_merge_result merge_status;
diff --git a/merge-recursive.c b/merge-recursive.c
index a0c3e7a2d91..02b7b584f95 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1047,7 +1047,7 @@ static int merge_3way(struct merge_options *opt,
const int extra_marker_size)
{
mmfile_t orig, src1, src2;
- struct ll_merge_options ll_opts = {0};
+ struct ll_merge_options ll_opts = LL_MERGE_OPTIONS_INIT;
char *base, *name1, *name2;
enum ll_merge_result merge_status;
--
gitgitgadget
^ permalink raw reply related
* [PATCH 3/4] merge options: add a conflict style member
From: Phillip Wood via GitGitGadget @ 2024-03-08 14:14 UTC (permalink / raw)
To: git; +Cc: Phillip Wood, Phillip Wood
In-Reply-To: <pull.1684.git.1709907270.gitgitgadget@gmail.com>
From: Phillip Wood <phillip.wood@dunelm.org.uk>
Add a conflict_style member to `struct merge_options` and `struct
ll_merge_options` to allow callers to override the default conflict
style. This will be used in the next commit.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
---
merge-ll.c | 4 +++-
merge-ll.h | 5 ++++-
merge-ort.c | 1 +
merge-recursive.c | 3 +++
merge-recursive.h | 1 +
5 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/merge-ll.c b/merge-ll.c
index 6570707297d..bf1077ae092 100644
--- a/merge-ll.c
+++ b/merge-ll.c
@@ -128,7 +128,9 @@ static enum ll_merge_result ll_xdl_merge(const struct ll_merge_driver *drv_unuse
xmp.level = XDL_MERGE_ZEALOUS;
xmp.favor = opts->variant;
xmp.xpp.flags = opts->xdl_opts;
- if (git_xmerge_style >= 0)
+ if (opts->conflict_style >= 0)
+ xmp.style = opts->conflict_style;
+ else if (git_xmerge_style >= 0)
xmp.style = git_xmerge_style;
if (marker_size > 0)
xmp.marker_size = marker_size;
diff --git a/merge-ll.h b/merge-ll.h
index af1ee36abdb..d038ee0c1e8 100644
--- a/merge-ll.h
+++ b/merge-ll.h
@@ -78,11 +78,14 @@ struct ll_merge_options {
*/
unsigned extra_marker_size;
+ /* Override the global conflict style. */
+ int conflict_style;
+
/* Extra xpparam_t flags as defined in xdiff/xdiff.h. */
long xdl_opts;
};
-#define LL_MERGE_OPTIONS_INIT {0}
+#define LL_MERGE_OPTIONS_INIT { .conflict_style = -1 }
enum ll_merge_result {
LL_MERGE_ERROR = -1,
diff --git a/merge-ort.c b/merge-ort.c
index 4a02c3ecd99..a9ab4031451 100644
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -1966,6 +1966,7 @@ static int merge_3way(struct merge_options *opt,
ll_opts.renormalize = opt->renormalize;
ll_opts.extra_marker_size = extra_marker_size;
ll_opts.xdl_opts = opt->xdl_opts;
+ ll_opts.conflict_style = opt->conflict_style;
if (opt->priv->call_depth) {
ll_opts.virtual_ancestor = 1;
diff --git a/merge-recursive.c b/merge-recursive.c
index 02b7b584f95..33b5f9384e8 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1054,6 +1054,7 @@ static int merge_3way(struct merge_options *opt,
ll_opts.renormalize = opt->renormalize;
ll_opts.extra_marker_size = extra_marker_size;
ll_opts.xdl_opts = opt->xdl_opts;
+ ll_opts.conflict_style = opt->conflict_style;
if (opt->priv->call_depth) {
ll_opts.virtual_ancestor = 1;
@@ -3899,6 +3900,8 @@ void init_merge_options(struct merge_options *opt,
opt->renormalize = 0;
+ opt->conflict_style = -1;
+
merge_recursive_config(opt);
merge_verbosity = getenv("GIT_MERGE_VERBOSITY");
if (merge_verbosity)
diff --git a/merge-recursive.h b/merge-recursive.h
index 3d3b3e3c295..e67d38c3030 100644
--- a/merge-recursive.h
+++ b/merge-recursive.h
@@ -31,6 +31,7 @@ struct merge_options {
/* xdiff-related options (patience, ignore whitespace, ours/theirs) */
long xdl_opts;
+ int conflict_style;
enum {
MERGE_VARIANT_NORMAL = 0,
MERGE_VARIANT_OURS,
--
gitgitgadget
^ permalink raw reply related
* [PATCH 4/4] checkout: cleanup --conflict=<style> parsing
From: Phillip Wood via GitGitGadget @ 2024-03-08 14:14 UTC (permalink / raw)
To: git; +Cc: Phillip Wood, Phillip Wood
In-Reply-To: <pull.1684.git.1709907270.gitgitgadget@gmail.com>
From: Phillip Wood <phillip.wood@dunelm.org.uk>
Passing an invalid conflict style name such as "--conflict=bad" gives
the error message
error: unknown style 'bad' given for 'merge.conflictstyle'
which is unfortunate as it talks about a config setting rather than
the option given on the command line. This happens because the
implementation calls git_xmerge_config() to set the conflict style
using the value given on the command line. Use the newly added
parse_conflict_style() instead and pass the value down the call chain
to override the config setting. This also means we can avoid setting
up a struct config_context required for calling git_xmerge_config().
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
---
builtin/checkout.c | 37 ++++++++++++++++++++-----------------
t/t7201-co.sh | 6 ++++++
2 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 6ded58bd95c..f5055f059ad 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -91,7 +91,8 @@ struct checkout_opts {
int new_branch_log;
enum branch_track track;
struct diff_options diff_options;
- char *conflict_style;
+ char *conflict_style_name;
+ int conflict_style;
int branch_exists;
const char *prefix;
@@ -100,6 +101,8 @@ struct checkout_opts {
struct tree *source_tree;
};
+#define CHECKOUT_OPTS_INIT { .conflict_style = -1 }
+
struct branch_info {
char *name; /* The short name used */
char *path; /* The full name of a real branch */
@@ -251,7 +254,8 @@ static int checkout_stage(int stage, const struct cache_entry *ce, int pos,
}
static int checkout_merged(int pos, const struct checkout *state,
- int *nr_checkouts, struct mem_pool *ce_mem_pool)
+ int *nr_checkouts, struct mem_pool *ce_mem_pool,
+ int conflict_style)
{
struct cache_entry *ce = the_index.cache[pos];
const char *path = ce->name;
@@ -286,6 +290,7 @@ static int checkout_merged(int pos, const struct checkout *state,
git_config_get_bool("merge.renormalize", &renormalize);
ll_opts.renormalize = renormalize;
+ ll_opts.conflict_style = conflict_style;
merge_status = ll_merge(&result_buf, path, &ancestor, "base",
&ours, "ours", &theirs, "theirs",
state->istate, &ll_opts);
@@ -416,7 +421,8 @@ static int checkout_worktree(const struct checkout_opts *opts,
else if (opts->merge)
errs |= checkout_merged(pos, &state,
&nr_unmerged,
- &ce_mem_pool);
+ &ce_mem_pool,
+ opts->conflict_style);
pos = skip_same_name(ce, pos) - 1;
}
}
@@ -886,6 +892,7 @@ static int merge_working_tree(const struct checkout_opts *opts,
}
o.branch1 = new_branch_info->name;
o.branch2 = "local";
+ o.conflict_style = opts->conflict_style;
ret = merge_trees(&o,
new_tree,
work,
@@ -1628,7 +1635,7 @@ static struct option *add_common_options(struct checkout_opts *opts,
PARSE_OPT_OPTARG, option_parse_recurse_submodules_worktree_updater),
OPT_BOOL(0, "progress", &opts->show_progress, N_("force progress reporting")),
OPT_BOOL('m', "merge", &opts->merge, N_("perform a 3-way merge with the new branch")),
- OPT_STRING(0, "conflict", &opts->conflict_style, N_("style"),
+ OPT_STRING(0, "conflict", &opts->conflict_style_name, N_("style"),
N_("conflict style (merge, diff3, or zdiff3)")),
OPT_END()
};
@@ -1720,14 +1727,13 @@ static int checkout_main(int argc, const char **argv, const char *prefix,
opts->show_progress = isatty(2);
}
- if (opts->conflict_style) {
- struct key_value_info kvi = KVI_INIT;
- struct config_context ctx = {
- .kvi = &kvi,
- };
+ if (opts->conflict_style_name) {
opts->merge = 1; /* implied */
- git_xmerge_config("merge.conflictstyle", opts->conflict_style,
- &ctx, NULL);
+ opts->conflict_style =
+ parse_conflict_style(opts->conflict_style_name);
+ if (opts->conflict_style < 0)
+ die(_("unknown conflict style '%s'"),
+ opts->conflict_style_name);
}
if (opts->force) {
opts->discard_changes = 1;
@@ -1893,7 +1899,7 @@ static int checkout_main(int argc, const char **argv, const char *prefix,
int cmd_checkout(int argc, const char **argv, const char *prefix)
{
- struct checkout_opts opts;
+ struct checkout_opts opts = CHECKOUT_OPTS_INIT;
struct option *options;
struct option checkout_options[] = {
OPT_STRING('b', NULL, &opts.new_branch, N_("branch"),
@@ -1909,7 +1915,6 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
int ret;
struct branch_info new_branch_info = { 0 };
- memset(&opts, 0, sizeof(opts));
opts.dwim_new_local_branch = 1;
opts.switch_branch_doing_nothing_is_ok = 1;
opts.only_merge_on_switching_branches = 0;
@@ -1948,7 +1953,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
int cmd_switch(int argc, const char **argv, const char *prefix)
{
- struct checkout_opts opts;
+ struct checkout_opts opts = CHECKOUT_OPTS_INIT;
struct option *options = NULL;
struct option switch_options[] = {
OPT_STRING('c', "create", &opts.new_branch, N_("branch"),
@@ -1964,7 +1969,6 @@ int cmd_switch(int argc, const char **argv, const char *prefix)
int ret;
struct branch_info new_branch_info = { 0 };
- memset(&opts, 0, sizeof(opts));
opts.dwim_new_local_branch = 1;
opts.accept_ref = 1;
opts.accept_pathspec = 0;
@@ -1990,7 +1994,7 @@ int cmd_switch(int argc, const char **argv, const char *prefix)
int cmd_restore(int argc, const char **argv, const char *prefix)
{
- struct checkout_opts opts;
+ struct checkout_opts opts = CHECKOUT_OPTS_INIT;
struct option *options;
struct option restore_options[] = {
OPT_STRING('s', "source", &opts.from_treeish, "<tree-ish>",
@@ -2007,7 +2011,6 @@ int cmd_restore(int argc, const char **argv, const char *prefix)
int ret;
struct branch_info new_branch_info = { 0 };
- memset(&opts, 0, sizeof(opts));
opts.accept_ref = 0;
opts.accept_pathspec = 1;
opts.empty_pathspec_ok = 0;
diff --git a/t/t7201-co.sh b/t/t7201-co.sh
index 10cc6c46051..5746d152b6d 100755
--- a/t/t7201-co.sh
+++ b/t/t7201-co.sh
@@ -631,6 +631,12 @@ test_expect_success 'checkout --conflict=diff3' '
test_cmp merged file
'
+test_expect_success 'checkout with invalid conflict style' '
+ test_must_fail git checkout --conflict=bad 2>actual -- file &&
+ echo "fatal: unknown conflict style ${SQ}bad${SQ}" >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'failing checkout -b should not break working tree' '
git clean -fd && # Remove untracked files in the way
git reset --hard main &&
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH 1/1] Documentation/user-manual.txt: example for generating object hashes
From: Junio C Hamano @ 2024-03-08 15:24 UTC (permalink / raw)
To: Dirk Gouders; +Cc: git
In-Reply-To: <ghbk7p43xq.fsf@gouders.net>
Dirk Gouders <dirk@gouders.net> writes:
> May I ask what you meant by "modulo coding style", e.g. where I should
> look at to make the code of similar style?
Documentation/CodingGuidelines would be a good start, but
* A here-doc for a single liner is probably an overkill. Why not
echo "Hello, world" >file
In either way, in our codebase a redirection operator '>' (or
'<') has one whitespace before it, and no whitespace after it
before the file.
* printf piped to "cat - file" whose output feeds another pipe
looked unusual. More usual way novices write may be
{ printf ... ; cat file; } | sha1sum
were the two things I noticed.
> I would also add that git-hash-object(1) could be used to verify the
> result if you think that is OK.
git hash-object can be used to replace that whole thing ;-)
> In addition to a suggestion in another mail, the commit would
> consist of substantial content you suggested and perhaps, you could tell
> me how to express this; would a Helped-By be correct?
I think many may prefer to downcase B in By, but if it is
"substantial", probably. I do not think I gave much in this
discussion to become a substantial addition to the original, though.
^ permalink raw reply
* Re: [PATCH] wt-status: Don't find scissors line beyond buf len
From: Junio C Hamano @ 2024-03-08 15:26 UTC (permalink / raw)
To: Florian Schmidt
Cc: git, Jonathan Davies, Phillip Wood, Denton Liu, Linus Arver
In-Reply-To: <1ff36e64-b993-4cbb-ba0a-01aca5396ef6@nutanix.com>
Florian Schmidt <flosch@nutanix.com> writes:
> Do you want me to send this version as a v2 to you + the list as per
> the documentation?
It would be the technically correct way to do so, but as a short-cut
to reduce a round-trip, if you are happy with the version I queued
(should be found by fetching the 'seen' branch from any of the
mirrors), you can just say "that looks fine" and we can be done with
this patch.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2024, #02; Thu, 7)
From: Junio C Hamano @ 2024-03-08 15:37 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <CAP8UFD1oWrE-C0XYi47PrBF36bJzHAv-jOq3r1UXw_BVnb97pA@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> (Sorry for sending this first privately to Junio by mistake.)
>
> On Fri, Mar 8, 2024 at 3:27 AM Junio C Hamano <gitster@pobox.com> wrote:
>
>> * cc/rev-list-allow-missing-tips (2024-02-28) 5 commits
>> (merged to 'next' on 2024-03-01 at fd7b109d04)
>> + revision: fix --missing=[print|allow*] for annotated tags
>> (merged to 'next' on 2024-03-01 at ac0fc94378)
>> + rev-list: allow missing tips with --missing=[print|allow*]
>> + t6022: fix 'test' style and 'even though' typo
>> + oidset: refactor oidset_insert_from_set()
>> + revision: clarify a 'return NULL' in get_reference()
>>
>> Originally merged to 'next' on 2024-02-28
>>
>> "git rev-list --missing=print" has learned to optionally take
>> "--allow-missing-tips", which allows the objects at the starting
>> points to be missing.
>
> The description might want to be updated as no new
> "--allow-missing-tips" option is introduced anymore. Maybe something
> like this instead:
>
> "git rev-list --missing=[print|allow*]" has learned to not die when
> some tips passed to it as command line arguments are missing. Instead
> those tips are just reported among the missing objects and ignored for
> traversal.
Thanks for a comment; better late than never. We'd probably need to
update the release notes, as this is gone from the list of cooking
topics already.
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2024, #02; Thu, 7)
From: Junio C Hamano @ 2024-03-08 15:42 UTC (permalink / raw)
To: Phillip Wood; +Cc: git
In-Reply-To: <f7cd227f-dcde-4d71-b1a6-a4d34c492cd1@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 08/03/2024 02:26, Junio C Hamano wrote:
>> * rs/t-ctype-simplify (2024-03-03) 4 commits
>> (merged to 'next' on 2024-03-04 at 9bd84a8877)
>> + t-ctype: avoid duplicating class names
>> + t-ctype: align output of i
>> + t-ctype: simplify EOF check
>> + t-ctype: allow NUL anywhere in the specification string
>> Code simplification to one unit-test program.
>> Will merge to 'master'.
>> source: <20240303101330.20187-1-l.s.r@web.de>
>
> I have some concerns about the last patch of this series
> c.f. <0947cb09-8b07-4fcd-bbe2-ae37c2cd5ec7@gmail.com> It might be too
> late for this series but using the internal implementation functions
> rather than TEST() is not a pattern that I would want us to encourage.
I actually think it is merely showing the lack of necessary features
in TEST() and other public macros/functions of the relatively new
low level test framework. If a user of the framework needs to use
the "internal implementation functions", that gives an incentive to
those who are pushing for the test framework to polish and update it,
so that such a framework client does not have to go deep into the
implementation details. When they come up with an improved framework,
they naturally have the first target to adjust to the framework to
demonstrate that they made the world a better place ;-)
And I think such an update can come after the dust settles in this
case. It is just a single simple test that is isolated and nobody
other than the unit-test folks should care about, as the subject of
test has not seen any change for a long time.
^ permalink raw reply
* Re: [PATCH 0/4] checkout: cleanup --conflict=
From: Junio C Hamano @ 2024-03-08 15:44 UTC (permalink / raw)
To: Phillip Wood via GitGitGadget; +Cc: git, Phillip Wood
In-Reply-To: <pull.1684.git.1709907270.gitgitgadget@gmail.com>
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
Here is a place to say why this series exists. Saying things like
"'checkout --conflict=bad' gives a wrong error message, as if the
inalid conflict style were given by a configuration variable, and
this is to fix that bug".
> Phillip Wood (4):
> xdiff-interface: refactor parsing of merge.conflictstyle
> merge-ll: introduce LL_MERGE_OPTIONS_INIT
> merge options: add a conflict style member
> checkout: cleanup --conflict=<style> parsing
>
> builtin/checkout.c | 40 +++++++++++++++++++++-------------------
> merge-ll.c | 6 ++++--
> merge-ll.h | 5 +++++
> merge-ort.c | 3 ++-
> merge-recursive.c | 5 ++++-
> merge-recursive.h | 1 +
> t/t7201-co.sh | 6 ++++++
> xdiff-interface.c | 29 ++++++++++++++++++-----------
> xdiff-interface.h | 1 +
> 9 files changed, 62 insertions(+), 34 deletions(-)
>
>
> base-commit: b387623c12f3f4a376e4d35a610fd3e55d7ea907
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1684%2Fphillipwood%2Frefactor-conflict-style-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1684/phillipwood/refactor-conflict-style-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/1684
^ permalink raw reply
* Re: [PATCH 3/4] merge options: add a conflict style member
From: Junio C Hamano @ 2024-03-08 15:46 UTC (permalink / raw)
To: Phillip Wood via GitGitGadget; +Cc: git, Phillip Wood
In-Reply-To: <c0d7bafd43823ef9df5a73bc80b90cf003988bc9.1709907271.git.gitgitgadget@gmail.com>
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> diff --git a/merge-ll.c b/merge-ll.c
> index 6570707297d..bf1077ae092 100644
> --- a/merge-ll.c
> +++ b/merge-ll.c
> ..
> -#define LL_MERGE_OPTIONS_INIT {0}
> +#define LL_MERGE_OPTIONS_INIT { .conflict_style = -1 }
Makes sense, and this obviously makes the previous step worth doing.
It looks quite wrong that low-level merge options definition is
hosted in a file whose name is merge low-level. Is it too late to
rename the file to fix this, by the way?
Thanks.
^ permalink raw reply
* Re: [PATCH 11/15] find multi-byte comment chars in unterminated buffers
From: Junio C Hamano @ 2024-03-08 15:58 UTC (permalink / raw)
To: Phillip Wood
Cc: René Scharfe, Jeff King, git, Dragan Simic,
Kristoffer Haugsbakk, Manlio Perillo
In-Reply-To: <d82e11f2-15c1-4ecb-8c7c-19667d2c5fb4@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> I agree with your analysis. I do wonder though if we should reject
> whitespace and control characters when parsing core.commentChar, it
> feels like accepting them is a bug waiting to happen. If
> comment_line_char starts with ' ' or '\t' that part will be eaten by
> the strspn() above and so starts_with_mem() wont match. Also we will
> never match a comment if comment_line_str contains '\n'.
Another thing I was wondering is what we want to do a random
byte-sequence that may match from the middle of a multi-byte UTF-8
character.
The reason I haven't mentioned these "nonsense input" is because
they will at worst only lead to self-denial-of-service to those who
are too curious, and will fall into "don't do it then" category.
Also, what exactly is the definition of "nonsense" will become can
of worms. I can sympathise if somebody wants to use "#\t" to give
themselves a bit more room than usual on the left for visibility,
for example, so there might be a case to want whitespace characters.
>> Not sure why lines that start with CR are considered comment lines,
>> though.
>
> I think it is a lazy way of looking for an empty line ending in CR LF,
> it should really be
>
> || (bol[0] == '\r' && bol[1] == '\n') ||
My recollection matches your speculation.
IIRC the lazy persono was probably me but I didn't run "git blame".
^ permalink raw reply
* Re: [PATCH 0/4] checkout: cleanup --conflict=
From: phillip.wood123 @ 2024-03-08 16:07 UTC (permalink / raw)
To: Junio C Hamano, Phillip Wood via GitGitGadget
Cc: git, Phillip Wood, Johannes Schindelin
In-Reply-To: <xmqqplw4hgnq.fsf@gitster.g>
Hi Junio
[cc Johannes for the gitgitgadget issue]
On 08/03/2024 15:44, Junio C Hamano wrote:
> "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> Here is a place to say why this series exists. Saying things like
> "'checkout --conflict=bad' gives a wrong error message, as if the
> inalid conflict style were given by a configuration variable, and
> this is to fix that bug".
Sorry, I'm not sure what happen there, I definitely entered a
cover-letter on the gitgitgadget PR:
Passing an invalid conflict style name such as "--conflict=bad" to "git
checkout" gives the error message
error: unknown style 'bad' given for 'merge.conflictstyle'
which is unfortunate as it talks about a config setting rather than the
option given on the command line. This series refactors the
implementation to pass the conflict style down the call chain to the
merge machinery rather than abusing the config setting.
Best Wishes
Phillip
>> Phillip Wood (4):
>> xdiff-interface: refactor parsing of merge.conflictstyle
>> merge-ll: introduce LL_MERGE_OPTIONS_INIT
>> merge options: add a conflict style member
>> checkout: cleanup --conflict=<style> parsing
>>
>> builtin/checkout.c | 40 +++++++++++++++++++++-------------------
>> merge-ll.c | 6 ++++--
>> merge-ll.h | 5 +++++
>> merge-ort.c | 3 ++-
>> merge-recursive.c | 5 ++++-
>> merge-recursive.h | 1 +
>> t/t7201-co.sh | 6 ++++++
>> xdiff-interface.c | 29 ++++++++++++++++++-----------
>> xdiff-interface.h | 1 +
>> 9 files changed, 62 insertions(+), 34 deletions(-)
>>
>>
>> base-commit: b387623c12f3f4a376e4d35a610fd3e55d7ea907
>> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1684%2Fphillipwood%2Frefactor-conflict-style-v1
>> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1684/phillipwood/refactor-conflict-style-v1
>> Pull-Request: https://github.com/gitgitgadget/git/pull/1684
^ 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