* Problem in gitweb.cgi
From: Marcelo Roberto Jimenez @ 2024-01-10 0:43 UTC (permalink / raw)
To: git
Hi,
I have recently run into a problem with gitweb that was triggered by
my distribution, OpenSUSE Tumbleweed. Due to a misconfiguration of the
application AppArmour, "git instaweb" was having problems in accessing
the configuration file "/etc/gitweb-common.conf". That was half of the
problem and has been reported downstream here:
https://bugzilla.suse.com/show_bug.cgi?id=1218664
The other half of the problem is in gitweb.cgi itself. There is a
logic to select which configuration file is going to be used. That
logic is ok, although a bit unclear from the documentation. Reading
the code I understood that $GITWEB_CONFIG_COMMON (usually
/etc/gitweb-common.conf) should always be read if it exists, and
$GITWEB_CONFIG_SYSTEM (usually /etc/gitweb.conf) will never be read if
$GITWEB_CONFIG has been read before.
The problem is that $GITWEB_CONFIG_COMMON was never read, even though
the code that reads it was being called before the code that reads the
other two files. As I said before, the problem was caused by a lack of
permission in AppArmour, but gitweb should have been able to catch the
error. By not signaling it properly, users get lost because the
problem is a little tricky to debug.
After some "printf" debugging, I converged to this routine, line 728
of gitweb.cgi:
# read and parse gitweb config file given by its parameter.
# returns true on success, false on recoverable error, allowing
# to chain this subroutine, using first file that exists.
# dies on errors during parsing config file, as it is unrecoverable.
sub read_config_file {
my $filename = shift;
return unless defined $filename;
# die if there are errors parsing config file
if (-e $filename) {
do $filename;
die $@ if $@;
return 1;
}
return;
}
Perl uses two different variables to manage errors from a "do". One is
"$@", which is set in this case when do is unable to compile the file.
The other is $!, which is set in case "do" cannot read the file. By
printing the value of $! I found out that it was set to "Permission
denied". Since the script does not currently test for $!, the error
goes unnoticed.
I suppose a proper fix would be to put a line before the test for $@,
like "die $! if $!".
For the curious, I have a report explaining the full problem here, but
the part relevant to gitweb is in this e-mail:
https://stackoverflow.com/questions/77789216/problem-with-git-instaweb-on-opensuse-tumbleweed-etc-gitweb-common-conf-is-n
Best regards,
Marcelo.
^ permalink raw reply
* What's cooking in git.git (Jan 2024, #03; Tue, 9)
From: Junio C Hamano @ 2024-01-10 0:17 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).
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']
* en/header-cleanup (2023-12-26) 12 commits
(merged to 'next' on 2023-12-28 at 1ccddc2a10)
+ treewide: remove unnecessary includes in source files
+ treewide: add direct includes currently only pulled in transitively
+ trace2/tr2_tls.h: remove unnecessary include
+ submodule-config.h: remove unnecessary include
+ pkt-line.h: remove unnecessary include
+ line-log.h: remove unnecessary include
+ http.h: remove unnecessary include
+ fsmonitor--daemon.h: remove unnecessary includes
+ blame.h: remove unnecessary includes
+ archive.h: remove unnecessary include
+ treewide: remove unnecessary includes in source files
+ treewide: remove unnecessary includes from header files
Remove unused header "#include".
source: <pull.1617.v2.git.1703351700.gitgitgadget@gmail.com>
* en/sparse-checkout-eoo (2023-12-26) 2 commits
(merged to 'next' on 2023-12-28 at 3ddf2ebab6)
+ sparse-checkout: be consistent with end of options markers
+ Merge branch 'jk/end-of-options' into jc/sparse-checkout-set-add-end-of-options
"git sparse-checkout (add|set) --[no-]cone --end-of-options" did
not handle "--end-of-options" correctly after a recent update.
source: <pull.1625.v2.git.git.1703619562639.gitgitgadget@gmail.com>
* jc/archive-list-with-extra-args (2023-12-21) 1 commit
(merged to 'next' on 2023-12-28 at 2d5c20e67f)
+ archive: "--list" does not take further options
"git archive --list extra garbage" silently ignored excess command
line parameters, which has been corrected.
source: <xmqqmsu3mnix.fsf@gitster.g>
* jc/sparse-checkout-set-default-fix (2023-12-26) 1 commit
(merged to 'next' on 2023-12-28 at a558eccf8e)
+ sparse-checkout: use default patterns for 'set' only !stdin
"git sparse-checkout set" added default patterns even when the
patterns are being fed from the standard input, which has been
corrected.
source: <20231221065925.3234048-3-gitster@pobox.com>
* ml/doc-merge-updates (2023-12-20) 2 commits
(merged to 'next' on 2023-12-28 at 7a6329a219)
+ Documentation/git-merge.txt: use backticks for command wrapping
+ Documentation/git-merge.txt: fix reference to synopsis
Doc update.
source: <20231220195342.17590-1-mi.al.lohmann@gmail.com>
* rs/fast-import-simplify-mempool-allocation (2023-12-26) 1 commit
(merged to 'next' on 2023-12-28 at 16e6dd2a69)
+ fast-import: use mem_pool_calloc()
Code simplification.
source: <50c1f410-ca37-4c1c-a28b-3e9fad49f2b4@web.de>
* rs/mem-pool-improvements (2023-12-28) 2 commits
(merged to 'next' on 2023-12-28 at aa03d9441c)
+ mem-pool: simplify alignment calculation
+ mem-pool: fix big allocations
MemPool allocator fixes.
source: <fa89d269-1a23-4ed6-bebc-30c0b629f444@web.de>
--------------------------------------------------
[New Topics]
* ps/gitlab-ci-static-analysis (2024-01-08) 1 commit
- ci: add job performing static analysis on GitLab CI
GitLab CI update.
Will merge to 'next'.
source: <1536a5ef07ad24dafb5d685b40099882f89e6cc5.1703761005.git.ps@pks.im>
* ps/prompt-parse-HEAD-futureproof (2024-01-08) 2 commits
- git-prompt: stop manually parsing HEAD with unknown ref formats
- Merge branch 'ps/refstorage-extension' into ps/prompt-parse-HEAD-futureproof
(this branch uses ps/refstorage-extension.)
Futureproof command line prompt support (in contrib/).
Will merge to 'next'.
source: <ef4e36a5a40c369da138242a8fdc9e12a846613b.1704356313.git.ps@pks.im>
* ps/reftable-optimize-io (2024-01-08) 4 commits
- reftable/blocksource: use mmap to read tables
- reftable/stack: use stat info to avoid re-reading stack list
- reftable/stack: refactor reloading to use file descriptor
- reftable/stack: refactor stack reloading to have common exit path
Low-level I/O optimization for reftable.
Will merge to 'next'?
source: <cover.1704714575.git.ps@pks.im>
* rj/clarify-branch-doc-m (2024-01-08) 1 commit
- branch: clarify <oldbranch> term
Doc update.
Will merge to 'next'.
source: <d38e5a18-4d85-48f3-bc8b-8ca02ea683a4@gmail.com>
* tb/fetch-all-configuration (2024-01-08) 1 commit
- fetch: add new config option fetch.all
"git fetch" learned to pay attention to "fetch.all" configuration
variable, which pretends as if "--all" was passed from the command
line when no remote parameter was given.
Will merge to 'next'.
source: <20240108211832.47362-1-dev@tb6.eu>
* rj/advice-disable-how-to-disable (2024-01-09) 3 commits
- advice: allow disabling the automatic hint in advise_if_enabled()
- t/test-tool: handle -c <name>=<value> arguments
- t/test-tool: usage description
All conditional "advice" messages show how to turn them off, which
becomes repetitive. Add a configuration variable to omit the
instruction.
Expecting a reroll.
cf. <ZZ2QafUf/JxXYZU/@nand.local>
source: <7c68392c-af2f-4999-ae64-63221bf7833a@gmail.com>
* vd/fsck-submodule-url-test (2024-01-09) 3 commits
- submodule-config.c: strengthen URL fsck check
- t7450: test submodule urls
- submodule-config.h: move check_submodule_url
Tighten URL checks fsck makes in a URL recorded for submodules.
Will merge to 'next'?
source: <pull.1635.git.1704822817.gitgitgadget@gmail.com>
--------------------------------------------------
[Cooking]
* ms/rebase-insnformat-doc-fix (2024-01-03) 1 commit
(merged to 'next' on 2024-01-04 at d68f2be39b)
+ Documentation: fix statement about rebase.instructionFormat
Docfix.
Will merge to 'master'.
source: <pull.1629.git.git.1704305663254.gitgitgadget@gmail.com>
* cp/git-flush-is-an-env-bool (2024-01-04) 1 commit
(merged to 'next' on 2024-01-04 at b435a96ce8)
+ write-or-die: make GIT_FLUSH a Boolean environment variable
Unlike other environment variables that took the usual
true/false/yes/no as well as 0/1, GIT_FLUSH only understood 0/1,
which has been corrected.
Will merge to 'master'.
source: <pull.1628.v3.git.1704363617842.gitgitgadget@gmail.com>
* sd/negotiate-trace-fix (2024-01-03) 1 commit
- push: region_leave trace for negotiate_using_fetch
Tracing fix.
Waiting for a review response.
cf. <xmqqbka27zu9.fsf@gitster.g>
source: <20240103224054.1940209-1-delmerico@google.com>
* sk/mingw-owner-check-error-message-improvement (2024-01-08) 1 commit
- mingw: give more details about unsafe directory's ownership
In addition to (rather cryptic) Security Identifiers, show username
and domain in the error message when we barf on mismatch between
the Git directory and the current user.
Will merge to 'next'?
source: <20240108173837.20480-2-soekkle@freenet.de>
* ib/rebase-reschedule-doc (2024-01-05) 1 commit
(merged to 'next' on 2024-01-08 at d451d1f760)
+ rebase: clarify --reschedule-failed-exec default
Doc update.
Will merge to 'master'.
source: <20240105011424.1443732-2-illia.bobyr@gmail.com>
* jk/commit-graph-slab-clear-fix (2024-01-05) 1 commit
(merged to 'next' on 2024-01-08 at f78c4fc296)
+ commit-graph: retain commit slab when closing NULL commit_graph
Clearing in-core repository (happens during e.g., "git fetch
--recurse-submodules" with commit graph enabled) made in-core
commit object in an inconsistent state by discarding the necessary
data from commit-graph too early, which has been corrected.
Will merge to 'master'.
source: <20240105054142.GA2035092@coredump.intra.peff.net>
* jk/index-pack-lsan-false-positive-fix (2024-01-05) 1 commit
(merged to 'next' on 2024-01-08 at 589ed65251)
+ index-pack: spawn threads atomically
Fix false positive reported by leak sanitizer.
Will merge to 'master'.
source: <20240105085034.GA3078476@coredump.intra.peff.net>
* cp/sideband-array-index-comment-fix (2023-12-28) 1 commit
(merged to 'next' on 2024-01-08 at f906bc86f1)
+ sideband.c: remove redundant 'NEEDSWORK' tag
In-code comment fix.
Will merge to 'master'.
source: <pull.1625.v4.git.1703750460527.gitgitgadget@gmail.com>
* ps/worktree-refdb-initialization (2024-01-08) 7 commits
- builtin/worktree: create refdb via ref backend
- worktree: expose interface to look up worktree by name
- builtin/worktree: move setup of commondir file earlier
- refs/files: skip creation of "refs/{heads,tags}" for worktrees
- setup: move creation of "refs/" into the files backend
- refs: prepare `refs_init_db()` for initializing worktree refs
- Merge branch 'ps/refstorage-extension' into ps/worktree-refdb-initialization
(this branch uses ps/refstorage-extension.)
Instead of manually creating refs/ hierarchy on disk upon a
creation of a secondary worktree, which is only usable via the
files backend, use the refs API to populate it.
source: <cover.1704705733.git.ps@pks.im>
* cp/apply-core-filemode (2023-12-26) 3 commits
- apply: code simplification
- apply: correctly reverse patch's pre- and post-image mode bits
- apply: ignore working tree filemode when !core.filemode
"git apply" on a filesystem without filemode support have learned
to take a hint from what is in the index for the path, even when
not working with the "--index" or "--cached" option, when checking
the executable bit match what is required by the preimage in the
patch.
Needs review.
source: <20231226233218.472054-1-gitster@pobox.com>
* jk/t1006-cat-file-objectsize-disk (2024-01-03) 2 commits
(merged to 'next' on 2024-01-03 at a492c6355c)
+ t1006: prefer shell loop to awk for packed object sizes
(merged to 'next' on 2023-12-28 at d82812e636)
+ t1006: add tests for %(objectsize:disk)
Test update.
Will merge to 'master'.
source: <20231221094722.GA570888@coredump.intra.peff.net>
source: <20240103090152.GB1866508@coredump.intra.peff.net>
* js/contributor-docs-updates (2023-12-27) 9 commits
(merged to 'next' on 2024-01-02 at 0e072117cd)
+ SubmittingPatches: hyphenate non-ASCII
+ SubmittingPatches: clarify GitHub artifact format
+ SubmittingPatches: clarify GitHub visual
+ SubmittingPatches: provide tag naming advice
+ SubmittingPatches: update extra tags list
+ SubmittingPatches: discourage new trailers
+ SubmittingPatches: drop ref to "What's in git.git"
+ CodingGuidelines: write punctuation marks
+ CodingGuidelines: move period inside parentheses
Doc update.
Will merge to 'master'.
source: <pull.1623.v3.git.1703739324.gitgitgadget@gmail.com>
* al/unit-test-ctype (2024-01-05) 1 commit
- unit-tests: rewrite t/helper/test-ctype.c as a unit test
Move test-ctype helper to the unit-test framework.
Almost there.
cf. <a087f57c-ce72-45c7-8182-f38d0aca9030@web.de>
cf. <33c81610-0958-49da-b702-ba8d96ecf1d3@gmail.com>
source: <20240105161413.10422-1-ach.lumap@gmail.com>
* bk/bisect-doc-fix (2023-12-27) 1 commit
- doc: use singular form of repeatable path arg
Synopsis fix.
Expecting a reroll.
source: <3d46bca1-96d4-43ba-a912-1f7c76942287@smtp-relay.sendinblue.com>
* ja/doc-placeholders-fix (2023-12-26) 2 commits
- doc: enforce placeholders in documentation
- doc: enforce dashes in placeholders
Docfix.
Needs review.
source: <pull.1626.git.1703539287.gitgitgadget@gmail.com>
* ps/refstorage-extension (2024-01-02) 13 commits
(merged to 'next' on 2024-01-08 at f9a034803b)
+ t9500: write "extensions.refstorage" into config
+ builtin/clone: introduce `--ref-format=` value flag
+ builtin/init: introduce `--ref-format=` value flag
+ builtin/rev-parse: introduce `--show-ref-format` flag
+ t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar
+ setup: introduce GIT_DEFAULT_REF_FORMAT envvar
+ setup: introduce "extensions.refStorage" extension
+ setup: set repository's formats on init
+ setup: start tracking ref storage format
+ refs: refactor logic to look up storage backends
+ worktree: skip reading HEAD when repairing worktrees
+ t: introduce DEFAULT_REPO_FORMAT prereq
+ Merge branch 'ps/clone-into-reftable-repository' into ps/refstorage-extension
(this branch is used by ps/prompt-parse-HEAD-futureproof and ps/worktree-refdb-initialization.)
Introduce a new extension "refstorage" so that we can mark a
repository that uses a non-default ref backend, like reftable.
Will merge to 'master'.
source: <cover.1703833818.git.ps@pks.im>
* ps/reftable-fixes-and-optims (2024-01-03) 9 commits
(merged to 'next' on 2024-01-08 at 167d7685f8)
+ reftable/merged: transfer ownership of records when iterating
+ reftable/merged: really reuse buffers to compute record keys
+ reftable/record: store "val2" hashes as static arrays
+ reftable/record: store "val1" hashes as static arrays
+ reftable/record: constify some parts of the interface
+ reftable/writer: fix index corruption when writing multiple indices
+ reftable/stack: do not auto-compact twice in `reftable_stack_add()`
+ reftable/stack: do not overwrite errors when compacting
+ Merge branch 'ps/reftable-fixes' into ps/reftable-fixes-and-optims
More fixes and optimizations to the reftable backend.
Will merge to 'master'.
source: <cover.1704262787.git.ps@pks.im>
* tb/multi-pack-verbatim-reuse (2023-12-14) 26 commits
(merged to 'next' on 2024-01-04 at 891ac0fa2c)
+ t/perf: add performance tests for multi-pack reuse
+ pack-bitmap: enable reuse from all bitmapped packs
+ pack-objects: allow setting `pack.allowPackReuse` to "single"
+ t/test-lib-functions.sh: implement `test_trace2_data` helper
+ pack-objects: add tracing for various packfile metrics
+ pack-bitmap: prepare to mark objects from multiple packs for reuse
+ pack-revindex: implement `midx_pair_to_pack_pos()`
+ pack-revindex: factor out `midx_key_to_pack_pos()` helper
+ midx: implement `midx_preferred_pack()`
+ git-compat-util.h: implement checked size_t to uint32_t conversion
+ pack-objects: include number of packs reused in output
+ pack-objects: prepare `write_reused_pack_verbatim()` for multi-pack reuse
+ pack-objects: prepare `write_reused_pack()` for multi-pack reuse
+ pack-objects: pass `bitmapped_pack`'s to pack-reuse functions
+ pack-objects: keep track of `pack_start` for each reuse pack
+ pack-objects: parameterize pack-reuse routines over a single pack
+ pack-bitmap: return multiple packs via `reuse_partial_packfile_from_bitmap()`
+ pack-bitmap: simplify `reuse_partial_packfile_from_bitmap()` signature
+ ewah: implement `bitmap_is_empty()`
+ pack-bitmap: pass `bitmapped_pack` struct to pack-reuse functions
+ midx: implement `midx_locate_pack()`
+ midx: implement `BTMP` chunk
+ midx: factor out `fill_pack_info()`
+ pack-bitmap: plug leak in find_objects()
+ pack-bitmap-write: deep-clear the `bb_commit` slab
+ pack-objects: free packing_data in more places
Streaming spans of packfile data used to be done only from a
single, primary, pack in a repository with multiple packfiles. It
has been extended to allow reuse from other packfiles, too.
Will merge to 'master'.
cf. <ZXurD1NTZ4TAs7WZ@nand.local>
source: <cover.1702592603.git.me@ttaylorr.com>
* jc/bisect-doc (2023-12-09) 1 commit
- bisect: document "terms" subcommand more fully
Doc update.
Needs review.
source: <xmqqzfyjmk02.fsf@gitster.g>
* jw/builtin-objectmode-attr (2023-12-28) 1 commit
(merged to 'next' on 2024-01-02 at 4c3784b3a1)
+ attr: add builtin objectmode values support
The builtin_objectmode attribute is populated for each path
without adding anything in .gitattributes files, which would be
useful in magic pathspec, e.g., ":(attr:builtin_objectmode=100755)"
to limit to executables.
Will merge to 'master'.
cf. <xmqq5y0ssknj.fsf@gitster.g>
source: <20231116054437.2343549-1-jojwang@google.com>
* tb/pair-chunk-expect (2023-11-10) 8 commits
- midx: read `OOFF` chunk with `pair_chunk_expect()`
- midx: read `OIDL` 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 `OIDL` chunk with `pair_chunk_expect()`
- chunk-format: introduce `pair_chunk_expect()` helper
- Merge branch 'jk/chunk-bounds-more' into HEAD
Further code clean-up.
Needs review.
source: <cover.1699569246.git.me@ttaylorr.com>
* tb/path-filter-fix (2023-10-18) 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.
Expecting a reroll?
cf. <20231023202212.GA5470@szeder.dev>
source: <cover.1697653929.git.me@ttaylorr.com>
* ak/color-decorate-symbols (2023-10-23) 7 commits
- log: add color.decorate.pseudoref config variable
- refs: exempt pseudorefs from pattern prefixing
- refs: add pseudorefs array and iteration functions
- log: add color.decorate.ref config variable
- log: add color.decorate.symbol config variable
- log: use designated inits for decoration_colors
- config: restructure color.decorate documentation
A new config for coloring.
Needs review.
source: <20231023221143.72489-1-andy.koppe@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-12-14) 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.1702562879.git.zhiyou.jx@alibaba-inc.com>
* jx/sideband-chomp-newline-fix (2023-12-18) 3 commits
(merged to 'next' on 2024-01-04 at 1237898a22)
+ 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.
Will merge to 'master'.
source: <cover.1702823801.git.zhiyou.jx@alibaba-inc.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>
--------------------------------------------------
[Discarded]
* jc/sparse-checkout-eoo (2023-12-21) 4 commits
. sparse-checkout: tighten add_patterns_from_input()
. sparse-checkout: use default patterns for 'set' only !stdin
. SQUASH??? end-of-options test
. sparse-checkout: take care of "--end-of-options" in set/add/check-rules
"git sparse-checkout (add|set) --[no-]cone --end-of-options" did
not handle "--end-of-options" correctly after a recent update.
Superseded by the en/sparse-checkout-eoo topic.
source: <20231221065925.3234048-1-gitster@pobox.com>
* tb/merge-tree-write-pack (2023-10-23) 5 commits
. builtin/merge-tree.c: implement support for `--write-pack`
. bulk-checkin: introduce `index_tree_bulk_checkin_incore()`
. bulk-checkin: introduce `index_blob_bulk_checkin_incore()`
. bulk-checkin: generify `stream_blob_to_pack()` for arbitrary types
. bulk-checkin: extract abstract `bulk_checkin_source`
"git merge-tree" learned "--write-pack" to record its result
without creating loose objects.
Broken when an object created during a merge is needed to continue merge
cf. <CABPp-BEfy9VOvimP9==ry_rZXu=metOQ8s=_-XiG_Pdx9c06Ww@mail.gmail.com>
cf. <ZZWOtnP2IHNldcy6@nand.local>
source: <cover.1698101088.git.me@ttaylorr.com>
^ permalink raw reply
* Re: Bug: Git spawns subprocesses on windows
From: brian m. carlson @ 2024-01-09 22:56 UTC (permalink / raw)
To: Domen Golob; +Cc: git
In-Reply-To: <CAF6dN-oEy-svp+6Bw_NAeOMrWc61ObcZ4Q2huVj9PPK1EQHquw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]
On 2024-01-09 at 15:33:43, Domen Golob wrote:
> Hello,
> the problem is exactly the same as what was reported here on stackoverflow:
> c# - Git for windows seems to create sub-processes that never die -
> Stack Overflow
> https://stackoverflow.com/questions/69579065/git-for-windows-seems-to-create-sub-processes-that-never-die
>
> Additionally I have found out that:
> - a Git for Windows subprocess is created for each repository and
> every time a git command is issued this process grows in size and it
> never dies.
> - you cannot delete the .git folder from the terminal, but it works
> via file explorer
> - deleting the .git folder kills the Git for windows process
> - creating changes in several repos creates multiple processes, and
> sometimes the process is created as a subprocess
You probably want to contact Git for Windows at
https://github.com/git-for-windows/git. The reason I suggest that is
that this is usually not a behaviour we see on Unix, and seems to be
Windows-specific.
I don't know if it's possible to see command-line arguments of processes
on Windows like it is with `ps` on Unix, but including that information
if possible will be very useful to the maintainers. Without knowing
that information, it's very unlikely that anyone will be able to help
you since we don't know what's going on.
There are some possibilities of what's going on here:
* git gc is running.
* git maintenance or the fsmonitor is configured and is running.
* You have a non-default antivirus or monitoring software that causes
processes to hang or not complete, so one of Git's subprocesses can't
exit. If you're using such software, we usually recommend completely
removing it completely (disabling it is usually not sufficient),
rebooting, and testing again to make sure it's not the problem.
* You have some other process which is running which spawns Git commands
(editors, content indexers, etc.).
* We actually have a bug and some process is not waited for correctly,
and zombie processes manifest differently on Windows than on Unix.
* Something else I haven't considered.
However, as I said, you'll probably want to contact the Git for Windows
folks through their issue tracker.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/1] mingw: give more details about unsafe directory's ownership
From: Junio C Hamano @ 2024-01-09 22:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sören Krecker, sunshine, git
In-Reply-To: <e7594386-4a26-467d-bd27-8ac6268ad219@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
>> Because len_domain includes the terminating NUL for the domain part,
>> (*str)[len_domain-1] is that NUL, no? And that is what you want to
>> overwrite to make the two strings <d> <NUL> <u> <NUL> into a single
>> one <d> <slash> <u> <NUL>. So...
>
> But after a successful call, len_domain and len_user have been modified
> to contain the lengths of the names (not counting the NULs), ...
Ah, that is what I missed. Thanks.
^ permalink raw reply
* Re: [PATCH 0/3] allow disabling the automatic hint in advise_if_enabled()
From: Junio C Hamano @ 2024-01-09 22:32 UTC (permalink / raw)
To: Taylor Blau; +Cc: Rubén Justo, Git List
In-Reply-To: <ZZ2QafUf/JxXYZU/@nand.local>
Taylor Blau <me@ttaylorr.com> writes:
> On Tue, Jan 09, 2024 at 04:25:32PM +0100, Rubén Justo wrote:
>> Using advise_if_enabled() to display an advice will automatically
>> include instructions on how to disable the advice, along with the main
>> advice:
>>
>> hint: use --reapply-cherry-picks to include skipped commits
>> hint: Disable this message with "git config advice.skippedCherryPicks false"
>>
>> This may become distracting or "noisy" over time, while the user may
>> still want to receive the main advice.
>>
>> Let's have a switch to allow disabling this automatic advice.
>
> I reviewed this and had a couple of notes, mostly focused on what to
> call the new configuration option, and if we should be modifying the
> test-tool helpers to accept arbitrary configuration via command-line
> options.
>
> I think that we could reasonably drop the first two patches by
> imitating the existing style of t0018 more closely, but I don't feel all
> that strongly about it.
Even though I do not have a fundamental objection against test-tool
learning "-c key=val", I do not see a strong need for the first two
steps, either.
I actually have more problems with the primary change of this series
(in addition to that configuration knob is probably misnamed, as you
pointed out). How to disable the advice is an integral part of the
end-user experience about the conditional advice system. The idea
is to show it repeatedly, perhaps loud enough to be called "noisy",
so that the user learns to follow the suggestion given by the hint.
Until then, the user is expected to gradually learn to follow the
suggestion more and more, seeing the advice message less and less
often. If we rob the "how to disable THIS PARTICULAR message" and
gave only this line:
>> hint: use --reapply-cherry-picks to include skipped commits
it would become impossible to find how to disable it, once the user
get comfortable enough to pass --reapply-cherry-picks when it is
appropriate to do so. I do not think there is no quick way other
than grepping in the source to find that the user needs to disable
the skippedCherryPicks message (no, you can look at the output from
"git config --help" and find "skippedCherryPicks" if you know that
is the symbol to be found, but there is nothing to link the above
hint message to that particular help page entry).
I would understand if the proposed change were to change the
"advice.<key>" configuration variable from a Boolean to a tristate
(yes = default, no = disabled, always = give advice without
instruction), though. IOW, the message might look like so:
hint: use --reapply-cherry-picks to include skipped commits
hint: setting advice.skippedCherryPicks to 'false' disables this message
hint: and setting it to 'always' removes this additional instruction.
Then, those who find the hint always useful (because the particular
mistake the hint is given against is something the user commits very
rarely and the convenience of being reminded when it happens, which
is rare, outweigh the burden of learning what is suggested) may want
to set it to 'always' to accept that new choice.
But not the way the new feature is proposed.
Thanks.
^ permalink raw reply
* Re: what should "git clean -n -f [-d] [-x] <pattern>" do?
From: Sergey Organov @ 2024-01-09 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq34v6gswv.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> I think the current code makes "-n" take precedence, and ignores
> "-f".
To me it rather looks more like "-n" implies "-f", but then there is
"second -f" rule that makes things even more interesting:
"Git will refuse to modify untracked nested git repositories
(directories with a .git subdirectory) unless a second -f is given."
How do I figure what files will be deleted on
git clean -f -f
when "-n" behaves as you (or me) described? I.e., what
git clean -f -f -n
and
git clean -f -n
will output?
>
> Shouldn't it either
>
> (1) error out with "-n and -f cannot be used together", or
> (2) let "-n" and "-f" follow the usual "last one wins" rule?
>
> The latter may be logically cleaner but it is a change that breaks
> backward compatibility big time in a more dangerous direction, so it
> may not be desirable in practice, with too big a downside for a too
> little gain.
I agree (2) is too dangerous and surprising, and (1) is limiting: I
believe the user should be able to see what will be done on
git clean -f -f
by simply adding "-n" to the command-line.
So I figure I'd rather prefer yet another option:
(3) -n dry run: show what will be done once "-n" is removed.
This way, e.g.,
git clean
and
git clean -n
will produce exactly the same output with default configuration:
fatal: clean.requireForce defaults to true and neither -i, nor -f given; refusing to clean
and one will need to say, e.g.:
git clean -n -f
to get the list of files to be deleted with "git clean -f".
With (3) "-n" becomes orthogonal to "-f", resulting in predictable and
useful behavior.
BR,
-- Sergey Organov
^ permalink raw reply
* Re: [PATCH 3/3] submodule-config.c: strengthen URL fsck check
From: Junio C Hamano @ 2024-01-09 21:57 UTC (permalink / raw)
To: Victoria Dye via GitGitGadget; +Cc: git, Victoria Dye
In-Reply-To: <893071530d3b77d6b72b7f69a6dfb9947579865e.1704822817.git.gitgitgadget@gmail.com>
"Victoria Dye via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Victoria Dye <vdye@github.com>
>
> Update the validation of "curl URL" submodule URLs (i.e. those that specify
> an "http[s]" or "ftp[s]" protocol) in 'check_submodule_url()' to catch more
> invalid URLs. The existing validation using 'credential_from_url_gently()'
> parses certain URLs incorrectly, leading to invalid submodule URLs passing
> 'git fsck' checks. Conversely, 'url_normalize()' - used to validate remote
> URLs in 'remote_get()' - correctly identifies the invalid URLs missed by
> 'credential_from_url_gently()'.
>
> To catch more invalid cases, replace 'credential_from_url_gently()' with
> 'url_normalize()' followed by a 'url_decode()' and a check for newlines
> (mirroring 'check_url_component()' in the 'credential_from_url_gently()'
> validation).
Thanks. Left hand and right hand checking the same thing in
different ways and coming up with different result is never a happy
situation. Making sure we consistently use the same definition of
what the valid URLs are is a very welcome thing to do, of course.
> -test_expect_failure 'check urls' '
> +test_expect_success 'check urls' '
> cat >expect <<-\EOF &&
> ./bar/baz/foo.git
> https://example.com/foo.git
It is a bit unfortunate that from here we cannot tell which bogus
URLs in this test that were incorrectly accepted are now rejected.
Among the many bogus URLs in the input, we used to allow
http://example.com:test/foo.git
(we do not accept non-numeric representation of port numbers, so
http://example.com:http/foo.git would also be rejected), but with
this change, it is now rejected. All the other bogus ones are
rejected just as before this change.
Will queue. Thanks.
^ permalink raw reply
* Re: [PATCH 2/3] t7450: test submodule urls
From: Junio C Hamano @ 2024-01-09 21:38 UTC (permalink / raw)
To: Victoria Dye via GitGitGadget; +Cc: git, Victoria Dye
In-Reply-To: <cf7848edffca27931aad02c0652adf2715320d35.1704822817.git.gitgitgadget@gmail.com>
"Victoria Dye via GitGitGadget" <gitgitgadget@gmail.com> writes:
> +#define TEST_TOOL_CHECK_URL_USAGE \
> + "test-tool submodule check-url <url>"
> +static const char *submodule_check_url_usage[] = {
> + TEST_TOOL_CHECK_URL_USAGE,
> + NULL
> +};
Granted, the entry that follows this new one already uses the same
pattern, but TEST_TOOL_CHECK_URL_USAGE being used only once here and
nowhere else, with its name almost as long as the value it expands to,
I found it unnecessarily verbose and confusing.
> #define TEST_TOOL_IS_ACTIVE_USAGE \
> "test-tool submodule is-active <name>"
> static const char *submodule_is_active_usage[] = {
> +typedef int (*check_fn_t)(const char *);
> +
> /*
> * Exit non-zero if any of the submodule names given on the command line is
> * invalid. If no names are given, filter stdin to print only valid names
> * (which is primarily intended for testing).
> */
OK. As long as each of the input lines are unique, we can use the
usual "does the actual output match the expected?" to test many of
them at once, and notice if there is an extra one in the output that
shouldn't have been emitted, or there is a missing one that should
have.
> -static int check_name(int argc, const char **argv)
> +static int check_submodule(int argc, const char **argv, check_fn_t check_fn)
> {
> if (argc > 1) {
> while (*++argv) {
> - if (check_submodule_name(*argv) < 0)
> + if (check_fn(*argv) < 0)
Quite nice way to reuse what we already have, thanks to [1/3].
^ permalink raw reply
* Re: [PATCH v7 1/1] mingw: give more details about unsafe directory's ownership
From: Johannes Sixt @ 2024-01-09 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sören Krecker, sunshine, git
In-Reply-To: <xmqq8r4ygtkd.fsf@gitster.g>
Am 09.01.24 um 21:06 schrieb Junio C Hamano:
> Johannes Sixt <j6t@kdbg.org> writes:
>
>>> + LookupAccountSidA(NULL, sid, NULL, &len_user, NULL, &len_domain,
>>> + &pe_use);
>>
>> At this point, the function fails, so len_user and len_domain contain
>> the required buffer size (including the trailing NUL).
>
> So (*str)[len_domain] would be the trailing NUL after the domain
> part in the next call? Or would that be (*str)[len_domain-1]? I am
> puzzled by off-by-one with your "including the trailing NUL" remark.
"Required buffer size" must count the trailing NUL. So, the NUL would be
at (*str)[len_domain-1].
>
>>> + /*
>>> + * Alloc needed space of the strings
>>> + */
>>> + ALLOC_ARRAY((*str), (size_t)len_domain + (size_t)len_user);
>
> This obviously assumes for domain 'd' and user 'u', we want "d/u" and
> len_domain must be 1+1 (including NUL) and len_user must be 1+1
> (including NUL). But then ...
So, this allocates the exact amount that is required to contain the
names with the trailing NULs: 1+1 plus 1+1 in this example.
>
>>> + translate_sid_to_user = LookupAccountSidA(NULL, sid,
>>> + (*str) + len_domain, &len_user, *str, &len_domain, &pe_use);
>
> ... ((*str)+len_domain) is presumably the beginning of the user
> part, and (*str)+0) is where the domain part is to be stored.
Correct.
>
> Because len_domain includes the terminating NUL for the domain part,
> (*str)[len_domain-1] is that NUL, no? And that is what you want to
> overwrite to make the two strings <d> <NUL> <u> <NUL> into a single
> one <d> <slash> <u> <NUL>. So...
But after a successful call, len_domain and len_user have been modified
to contain the lengths of the names (not counting the NULs), so, here
the NUL is at (*str)[len_domain]...
>
>> At this point, if the function is successful, len_user and len_domain
>> contain the lengths of the names (without the trailing NUL).
>>
>>> + if (!translate_sid_to_user)
>>> + FREE_AND_NULL(*str);
>>> + else
>>> + (*str)[len_domain] = '/';
>
> ... this offset looks fishy to me. Am I off-by-one?
... and this offset is correct.
I followed the same train of thought and suspected an off-by-one error,
too, and was perplexed that I see a correct output. The documentation of
LookupAccountSid is unclear that the variables change values across the
(successful) call, but my tests verified that the change does happen.
>> Therefore, this overwrites the NUL after the domain name and so
>> concatenates the two names. Good.
>>
>> I found this by dumping the values of the variables, because the
>> documentation of LookupAccountSid is not clear about the values that the
>> variables receive in the success case.
>>
>>> + return translate_sid_to_user;
>>> +}
>>> +
>>
>> This patch looks good and works for me.
>>
>> Acked-by: Johannes Sixt <j6t@kdbg.org>
>>
>> Thank you!
>>
>> -- Hannes
-- Hannes
^ permalink raw reply
* what should "git clean -n -f [-d] [-x] <pattern>" do?
From: Junio C Hamano @ 2024-01-09 20:20 UTC (permalink / raw)
To: git
I think the current code makes "-n" take precedence, and ignores
"-f". Shouldn't it either
(1) error out with "-n and -f cannot be used together", or
(2) let "-n" and "-f" follow the usual "last one wins" rule?
The latter may be logically cleaner but it is a change that breaks
backward compatibility big time in a more dangerous direction, so it
may not be desirable in practice, with too big a downside for a too
little gain.
^ permalink raw reply
* Re: [PATCH v7 1/1] mingw: give more details about unsafe directory's ownership
From: Junio C Hamano @ 2024-01-09 20:06 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sören Krecker, sunshine, git
In-Reply-To: <d1e1a543-ab9c-4b1b-9f1d-3728e791df2e@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
>> + LookupAccountSidA(NULL, sid, NULL, &len_user, NULL, &len_domain,
>> + &pe_use);
>
> At this point, the function fails, so len_user and len_domain contain
> the required buffer size (including the trailing NUL).
So (*str)[len_domain] would be the trailing NUL after the domain
part in the next call? Or would that be (*str)[len_domain-1]? I am
puzzled by off-by-one with your "including the trailing NUL" remark.
>> + /*
>> + * Alloc needed space of the strings
>> + */
>> + ALLOC_ARRAY((*str), (size_t)len_domain + (size_t)len_user);
This obviously assumes for domain 'd' and user 'u', we want "d/u" and
len_domain must be 1+1 (including NUL) and len_user must be 1+1
(including NUL). But then ...
>> + translate_sid_to_user = LookupAccountSidA(NULL, sid,
>> + (*str) + len_domain, &len_user, *str, &len_domain, &pe_use);
... ((*str)+len_domain) is presumably the beginning of the user
part, and (*str)+0) is where the domain part is to be stored.
Because len_domain includes the terminating NUL for the domain part,
(*str)[len_domain-1] is that NUL, no? And that is what you want to
overwrite to make the two strings <d> <NUL> <u> <NUL> into a single
one <d> <slash> <u> <NUL>. So...
> At this point, if the function is successful, len_user and len_domain
> contain the lengths of the names (without the trailing NUL).
>
>> + if (!translate_sid_to_user)
>> + FREE_AND_NULL(*str);
>> + else
>> + (*str)[len_domain] = '/';
... this offset looks fishy to me. Am I off-by-one?
> Therefore, this overwrites the NUL after the domain name and so
> concatenates the two names. Good.
>
> I found this by dumping the values of the variables, because the
> documentation of LookupAccountSid is not clear about the values that the
> variables receive in the success case.
>
>> + return translate_sid_to_user;
>> +}
>> +
>
> This patch looks good and works for me.
>
> Acked-by: Johannes Sixt <j6t@kdbg.org>
>
> Thank you!
>
> -- Hannes
^ permalink raw reply
* Re: [PATCH 3/3] advice: allow disabling the automatic hint in advise_if_enabled()
From: Junio C Hamano @ 2024-01-09 19:57 UTC (permalink / raw)
To: Taylor Blau; +Cc: Rubén Justo, Git List
In-Reply-To: <ZZ2QGYBBmK8cSYBD@nand.local>
Taylor Blau <me@ttaylorr.com> writes:
> Looking at this test, I wonder why we don't imitate the existing style
> of:
>
> test_config advice.adviceOff false &&
> test-tool advise "This is a piece of advice" 2>actual &&
> test_cmp expect actual
>
> instead of teaching the test-tool helpers how to interpret `-c`
> arguments. Doing so would allow us to drop the first couple of patches
> in this series and simplify things a bit.
Thanks for a dose of sanity. I too got a bit too excited by a shiny
new toy ;-) Reusing the existing mechanism does make sense.
^ permalink raw reply
* [GSOC][RFC] Add more builtin patterns for userdiff, as Mircroproject.
From: Sergius Nyah @ 2024-01-09 19:55 UTC (permalink / raw)
To: git, gitster@pobox.com
Hello everyone,
I'm Sergius, a Computer Science undergraduate student, and I want to
begin Contributing to the Git project. So far, I've gone through
Matheus' tutorial on First steps Contributing to Git, and I found it
very helpful. I've also read the Contribution guidelines keenly and
built Git from source.
In accordance to the contributor guidelines, I came across this
Mircoproject idea from: https://git.github.io/SoC-2022-Microprojects/
which I'm willing to work on. It talked about enhancing Git's
"userdiff" feature in "userdiff.c" which is crucial for identifying
function names in various programming languages, thereby improving the
readability of "git diff" outputs.
From my understanding, the project involves extending the `userdiff`
feature to support additional programming languages that are currently
not covered such as Shell, Swift, Go and the others.
Here is a sample of how a language is defined in `userdiff.c`:
> #define PATTERNS(lang, rx, wrx) { \
> .name = lang, \
> .binary = -1, \
> .funcname = { \
> .pattern = rx, \
> .cflags = REG_EXTENDED, \
> }, \
> .word_regex = wrx "|[^[:space:]]|[\xc0-\xff][\x80-\xbf]+", \
> .word_regex_multi_byte = wrx "|[^[:space:]]", \
> }
In this code, `lang` is the name of the language, `rx` is the regular
expression for identifying function names, and `wrx` is the word
regex.
Approach: I Identified the Programming Languages that are not
currently supported by the userdiff feature by reviewing the existing
patterns in userdiff.c and comparing them with some popular
programming languages.
For each supported language, I would define a regular expression that
could help identify function names in that language. This could
include researching each language's syntax and testing their
expressions to ensure that they work well.
Also, I'd add a new IPATTERN definition for each language to the
"userdiff.c" file, then rebuild Git and test the changes by creating a
repo with files in the newly supported languages then run "git diff"
to ensure the line @@ ... @@ produces their correct function names.
Then submit a patch.
Best Regards!
Sergius.
^ permalink raw reply
* Add more builtin patterns for userdiff, as Microproject.
From: Sergius Nyah @ 2024-01-09 19:54 UTC (permalink / raw)
To: git, gitster@pobox.com; +Cc: newren, l.s.r
Hello everyone,
I'm Sergius, a Computer Science undergraduate student, and I want to
begin Contributing to the Git project. So far, I've gone through
Matheus' tutorial on First steps Contributing to Git, and I found it
very helpful. I've also read the Contribution guidelines keenly and
built Git from source.
In accordance with the contributor guidelines, I came across this
Mircoproject idea from: https://git.github.io/SoC-2022-Microprojects/
which I'm willing to work on. It talked about enhancing Git's
"userdiff" feature in "userdiff.c" which is crucial for identifying
function names in various programming languages, thereby improving the
readability of "git diff" outputs.
From my understanding, the project involves extending the `userdiff`
feature to support additional programming languages that are currently
not covered such as Shell, Swift, Go and the others.
Here is a sample of how a language is defined in `userdiff.c`:
> #define PATTERNS(lang, rx, wrx) { \
> .name = lang, \
> .binary = -1, \
> .funcname = { \
> .pattern = rx, \
> .cflags = REG_EXTENDED, \
> }, \
> .word_regex = wrx "|[^[:space:]]|[\xc0-\xff][\x80-\xbf]+", \
> .word_regex_multi_byte = wrx "|[^[:space:]]", \
> }
In this code, `lang` is the name of the language, `rx` is the regular
expression for identifying function names, and `wrx` is the word
regex.
Approach: I Identified the Programming Languages that are not
currently supported by the userdiff feature by reviewing the existing
patterns in userdiff.c and comparing them with some popular
programming languages.
For each supported language, I would define a regular expression that
could help identify function names in that language. This could
include researching each language's syntax and testing their
expressions to ensure that they work well.
Also, I'd add a new IPATTERN definition for each language to the
"userdiff.c" file, then rebuild Git and test the changes by creating a
repo with files in the newly supported languages then run "git diff"
to ensure the line @@ ... @@ produces their correct function names.
Then submit a patch.
Best Regards!
Sergius.
^ permalink raw reply
* Re: [PATCH 4/6] t1419: mark test suite as files-backend specific
From: Eric Sunshine @ 2024-01-09 19:40 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <d7c6b8b2a7b3b4d776f06ce577bdbdbaff66f225.1704802213.git.ps@pks.im>
On Tue, Jan 9, 2024 at 7:17 AM Patrick Steinhardt <ps@pks.im> wrote:
> With 59c35fac54 (refs/packed-backend.c: implement jump lists to avoid
> excluded pattern(s), 2023-07-10) we have implemented logic to handle
> excluded refs more efficiently in the "packed" ref backend. This logic
> allows us to skip emitting refs completely which we know to not be of
> any interest to the caller, which can avoid quite some allocaitons and
> object lookups.
s/allocaitons/allocations/
> This was wired up via a new `exclude_patterns` parameter passed to the
> backend's ref iterator. The backend only needs to handle them on a best
> effort basis though, and in fact we only handle it for the "packed-refs"
> file, but not for loose references. Consequentially, all callers must
> still filter emitted refs with those exclude patterns.
s/Consequentially/Consequently/
> The result is that handling exclude patterns is completely optional in
> the ref backend, and any future backends may or may not implement it.
> Let's thus mark the test for t1419 to depend on the REFFILES prereq.
This change seems to be abusing the meaning of the REFFILES
prerequisite. Instead the above description argues for introduction of
a new prerequisite which indicates whether or not the backend honors
the exclude patterns. Or, am I misunderstanding this?
^ permalink raw reply
* Re: [PATCH 1/6] t1300: mark tests to require default repo format
From: Eric Sunshine @ 2024-01-09 19:35 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <ec1b5bdd176e6a3f093b76b732fd9e960a7880ca.1704802213.git.ps@pks.im>
On Tue, Jan 9, 2024 at 7:17 AM Patrick Steinhardt <ps@pks.im> wrote:
> The t1300 test suite exercises the git-config(1) tool. To do so we
> overwrite ".git/config" to contain custom contents. While this is easy
> enough to do, it may create problems when using a non-default repository
> format because we also overwrite the repository format version as well
> as any potential extensions.
>
> Mark these tests with the DEFAULT_REPO_FORMAT prerequisite to avoid the
> problem. An alternative would be to carry over mandatory config keys
> into the rewritten config file. But the effort does not seem worth it
> given that the system under test is git-config(1), which is at a lower
> level than the repository format.
If I'm understanding correctly, with the approach taken by this patch,
won't we undesirably lose some git-config test coverage if the
file-based backend is ever retired, or if tests specific to it are
ever disabled by default? As such, it seems like the alternative "fix"
you mention above would be preferable to ensure that coverage of
git-config doesn't get diluted.
Or am I misunderstanding something?
^ permalink raw reply
* Re: [PATCH v7 1/1] mingw: give more details about unsafe directory's ownership
From: Johannes Sixt @ 2024-01-09 19:27 UTC (permalink / raw)
To: Sören Krecker; +Cc: sunshine, git
In-Reply-To: <20240108173837.20480-2-soekkle@freenet.de>
Am 08.01.24 um 18:38 schrieb Sören Krecker:
> +static BOOL user_sid_to_user_name(PSID sid, LPSTR *str)
> +{
> + SID_NAME_USE pe_use;
> + DWORD len_user = 0, len_domain = 0;
> + BOOL translate_sid_to_user;
> +
> + /*
> + * returns only FALSE, because the string pointers are NULL
> + */
> + LookupAccountSidA(NULL, sid, NULL, &len_user, NULL, &len_domain,
> + &pe_use);
At this point, the function fails, so len_user and len_domain contain
the required buffer size (including the trailing NUL).
> + /*
> + * Alloc needed space of the strings
> + */
> + ALLOC_ARRAY((*str), (size_t)len_domain + (size_t)len_user);
> + translate_sid_to_user = LookupAccountSidA(NULL, sid,
> + (*str) + len_domain, &len_user, *str, &len_domain, &pe_use);
At this point, if the function is successful, len_user and len_domain
contain the lengths of the names (without the trailing NUL).
> + if (!translate_sid_to_user)
> + FREE_AND_NULL(*str);
> + else
> + (*str)[len_domain] = '/';
Therefore, this overwrites the NUL after the domain name and so
concatenates the two names. Good.
I found this by dumping the values of the variables, because the
documentation of LookupAccountSid is not clear about the values that the
variables receive in the success case.
> + return translate_sid_to_user;
> +}
> +
This patch looks good and works for me.
Acked-by: Johannes Sixt <j6t@kdbg.org>
Thank you!
-- Hannes
^ permalink raw reply
* Re: [PATCH 5/6] t5526: break test submodule differently
From: Eric Sunshine @ 2024-01-09 19:23 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <51e494a50e4416ed0cbfd3c474ffcaf8b72e6ef4.1704802213.git.ps@pks.im>
On Tue, Jan 9, 2024 at 7:17 AM Patrick Steinhardt <ps@pks.im> wrote:
> In 10f5c52656 (submodule: avoid auto-discovery in
> prepare_submodule_repo_env(), 2016-09-01) we fixed a bug when doing a
> recursive fetch with submodule in the case where the submodule is broken
> due to whatever reason. The test to exercise that the fix works breaks
> the submodule by deleting its `HEAD` reference, which will cause us to
> not detect the directory as a Git repository.
>
> While this is perfectly fine in theory, this way of breaking the repo
> becomes problematic with the current efforts to introduce another refdb
> backend into Git. The new reftable backend has a stub HEAD file that
> always contains "ref: refs/heads/.invalid" so that tools continue to be
> able to detect such a repository. But as the reftable backend will never
> delete this file even when asked to delete `HEAD` the current way to
> delete the `HEAD` reference will stop working.
This patch is not the appropriate place to bikeshed (but since this is
the first time I've read or paid attention to it), if I saw "ref:
refs/heads/.invalid", the word ".invalid" would make me think
something was broken in my repository. Would it make sense to use some
less alarming word, such as perhaps ".placeholder", ".stand-in",
".synthesized" or even the name of the non-file-based backend in use?
> Adapt the code to instead delete the objects database. Going back with
> this new way to cuase breakage confirms that it triggers the infinite
> recursion just the same, and there are no equivalent ongoing efforts to
> replace the object database with an alternate backend.
s/cuase/cause/
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> diff --git a/t/t5526-fetch-submodules.sh b/t/t5526-fetch-submodules.sh
> @@ -771,7 +771,7 @@ test_expect_success 'fetching submodule into a broken repository' '
> # Break the receiving submodule
> - test-tool -C dst/sub ref-store main delete-refs REF_NO_DEREF msg HEAD &&
> + rm -r dst/sub/.git/objects &&
If there is no guarantee that .git/objects will exist when any
particular backend is in use, would it be more robust to use -f here,
as well?
rm -rf dst/sub/.git/objects &&
^ permalink raw reply
* Re: [PATCH 3/6] t1302: make tests more robust with new extensions
From: Taylor Blau @ 2024-01-09 18:43 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <9af1e418d47730f503dabb271d30c848bf74fa0b.1704802213.git.ps@pks.im>
On Tue, Jan 09, 2024 at 01:17:12PM +0100, Patrick Steinhardt wrote:
> In t1302 we exercise logic around "core.repositoryFormatVersion" and
> extensions. These tests are not particularly robust against extensions
> like the newly introduced "refStorage" extension.
>
> Refactor the tests to be more robust:
>
> - Check the DEFAULT_REPO_FORMAT prereq to determine the expected
> repository format version. This helps to ensure that we only need to
> update the prereq in a central place when new extensions are added.
>
> - Use a separate repository to rewrite ".git/config" to test
> combinations of the repository format version and extensions. This
> ensures that we don't break the main test repository.
>
> - Do not rewrite ".git/config" when exercising the "preciousObjects"
> extension.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> t/t1302-repo-version.sh | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh
> index 179474fa65..fb30c87e1b 100755
> --- a/t/t1302-repo-version.sh
> +++ b/t/t1302-repo-version.sh
> @@ -28,7 +28,12 @@ test_expect_success 'setup' '
> '
>
> test_expect_success 'gitdir selection on normal repos' '
> - test_oid version >expect &&
> + if test_have_prereq DEFAULT_REPO_FORMAT
> + then
> + echo 0
> + else
> + echo 1
> + fi >expect &&
> git config core.repositoryformatversion >actual &&
> git -C test config core.repositoryformatversion >actual2 &&
> test_cmp expect actual &&
> @@ -79,8 +84,13 @@ mkconfig () {
>
> while read outcome version extensions; do
> test_expect_success "$outcome version=$version $extensions" "
> - mkconfig $version $extensions >.git/config &&
> - check_${outcome}
> + test_when_finished 'rm -rf extensions' &&
> + git init extensions &&
> + (
> + cd extensions &&
> + mkconfig $version $extensions >.git/config &&
> + check_${outcome}
> + )
> "
> done <<\EOF
> allow 0
> @@ -94,7 +104,8 @@ allow 1 noop-v1
> EOF
>
> test_expect_success 'precious-objects allowed' '
> - mkconfig 1 preciousObjects >.git/config &&
> + git config core.repositoryformatversion 1 &&
I'm nit-picking, but it looks like core.repositoryformatversion is all
lower-case, whereas extensions.preciousObjects is camel-case. I don't
think it's a big deal either way, but I couldn't *not* mention it while
reading ;-)
> + git config extensions.preciousObjects 1 &&
> check_allow
> '
>
> --
> 2.43.GIT
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH 1/6] t1300: mark tests to require default repo format
From: Taylor Blau @ 2024-01-09 18:41 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <ec1b5bdd176e6a3f093b76b732fd9e960a7880ca.1704802213.git.ps@pks.im>
On Tue, Jan 09, 2024 at 01:17:04PM +0100, Patrick Steinhardt wrote:
> The t1300 test suite exercises the git-config(1) tool. To do so we
> overwrite ".git/config" to contain custom contents. While this is easy
> enough to do, it may create problems when using a non-default repository
> format because we also overwrite the repository format version as well
> as any potential extensions.
>
> Mark these tests with the DEFAULT_REPO_FORMAT prerequisite to avoid the
> problem. An alternative would be to carry over mandatory config keys
> into the rewritten config file. But the effort does not seem worth it
> given that the system under test is git-config(1), which is at a lower
> level than the repository format.
I think I am missing something obvious here ;-).
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> t/t1300-config.sh | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/t/t1300-config.sh b/t/t1300-config.sh
> index f4e2752134..1e953a0fc2 100755
> --- a/t/t1300-config.sh
> +++ b/t/t1300-config.sh
> @@ -1098,7 +1098,7 @@ test_expect_success SYMLINKS 'symlink to nonexistent configuration' '
> test_must_fail git config --file=linktolinktonada --list
> '
>
> -test_expect_success 'check split_cmdline return' "
> +test_expect_success DEFAULT_REPO_FORMAT 'check split_cmdline return' "
> git config alias.split-cmdline-fix 'echo \"' &&
> test_must_fail git split-cmdline-fix &&
> echo foo > foo &&
> @@ -1156,7 +1156,7 @@ test_expect_success 'git -c works with aliases of builtins' '
> test_cmp expect actual
> '
Looking at this first test, for example, I see two places where we
modify the configuration file:
- git config alias.split-cmdline-fix 'echo \"'
- git config branch.main.mergeoptions 'echo \"'
I think I am missing some detail about why we can't do this when we have
extensions enabled?
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH 0/3] allow disabling the automatic hint in advise_if_enabled()
From: Taylor Blau @ 2024-01-09 18:28 UTC (permalink / raw)
To: Rubén Justo; +Cc: Git List
In-Reply-To: <7c68392c-af2f-4999-ae64-63221bf7833a@gmail.com>
On Tue, Jan 09, 2024 at 04:25:32PM +0100, Rubén Justo wrote:
> Using advise_if_enabled() to display an advice will automatically
> include instructions on how to disable the advice, along with the main
> advice:
>
> hint: use --reapply-cherry-picks to include skipped commits
> hint: Disable this message with "git config advice.skippedCherryPicks false"
>
> This may become distracting or "noisy" over time, while the user may
> still want to receive the main advice.
>
> Let's have a switch to allow disabling this automatic advice.
I reviewed this and had a couple of notes, mostly focused on what to
call the new configuration option, and if we should be modifying the
test-tool helpers to accept arbitrary configuration via command-line
options.
I think that we could reasonably drop the first two patches by
imitating the existing style of t0018 more closely, but I don't feel all
that strongly about it.
So I would probably expect a reroll of this series, but if you disagree
with my comments, I would not be sad to see this series merged as-is.
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH 3/3] advice: allow disabling the automatic hint in advise_if_enabled()
From: Taylor Blau @ 2024-01-09 18:27 UTC (permalink / raw)
To: Rubén Justo; +Cc: Git List
In-Reply-To: <d6099d78-43c6-4709-9121-11f84228cf91@gmail.com>
On Tue, Jan 09, 2024 at 04:30:16PM +0100, Rubén Justo wrote:
> Using advise_if_enabled() to display an advice will automatically
> include instructions on how to disable the advice, along with the
> main advice:
>
> hint: use --reapply-cherry-picks to include skipped commits
> hint: Disable this message with "git config advice.skippedCherryPicks false"
>
> This can become distracting or noisy over time, while the user may
> still want to receive the main advice.
Presumably for more trivial pieces of advice, a user may want to
immediately disable those hints in the future more quickly after first
receiving the advice, in which case this feature may not be as useful
for them.
But for trickier pieces of advice, I agree completely with your
reasoning and think that something like this makes sense.
> Let's have a switch to allow disabling this automatic advice.
>
> Signed-off-by: Rubén Justo <rjusto@gmail.com>
> ---
> advice.c | 3 ++-
> advice.h | 3 ++-
> t/t0018-advice.sh | 8 ++++++++
> 3 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/advice.c b/advice.c
> index 50c79443ba..fa203f8806 100644
> --- a/advice.c
> +++ b/advice.c
> @@ -79,6 +79,7 @@ static struct {
> [ADVICE_UPDATE_SPARSE_PATH] = { "updateSparsePath", 1 },
> [ADVICE_WAITING_FOR_EDITOR] = { "waitingForEditor", 1 },
> [ADVICE_WORKTREE_ADD_ORPHAN] = { "worktreeAddOrphan", 1 },
> + [ADVICE_ADVICE_OFF] = { "adviceOff", 1 },
The name seems to imply that setting `advice.adviceOff=true` would cause
Git to suppress the turn-off instructions. But...
> };
>
> static const char turn_off_instructions[] =
> @@ -93,7 +94,7 @@ static void vadvise(const char *advice, int display_instructions,
>
> strbuf_vaddf(&buf, advice, params);
>
> - if (display_instructions)
> + if (display_instructions && advice_enabled(ADVICE_ADVICE_OFF))
> strbuf_addf(&buf, turn_off_instructions, key);
...it looks like the opposite is true. I guess the "adviceOff" part of
this new configuration option suggests "show me advice on how to turn
off advice of xyz kind in the future".
Perhaps a clearer alternative might be "advice.showDisableInstructions"
or something? I don't know, coming up with a direct/clear name of this
configuration is challenging for me.
>
> for (cp = buf.buf; *cp; cp = np) {
> diff --git a/advice.h b/advice.h
> index 2affbe1426..1f2eef034e 100644
> --- a/advice.h
> +++ b/advice.h
> @@ -10,7 +10,7 @@ struct string_list;
> * Add the new config variable to Documentation/config/advice.txt.
> * Call advise_if_enabled to print your advice.
> */
> - enum advice_type {
> +enum advice_type {
> ADVICE_ADD_EMBEDDED_REPO,
> ADVICE_ADD_EMPTY_PATHSPEC,
> ADVICE_ADD_IGNORED_FILE,
> @@ -50,6 +50,7 @@ struct string_list;
> ADVICE_WAITING_FOR_EDITOR,
> ADVICE_SKIPPED_CHERRY_PICKS,
> ADVICE_WORKTREE_ADD_ORPHAN,
> + ADVICE_ADVICE_OFF,
> };
>
> int git_default_advice_config(const char *var, const char *value);
> diff --git a/t/t0018-advice.sh b/t/t0018-advice.sh
> index c13057a4ca..0b6a8b4a10 100755
> --- a/t/t0018-advice.sh
> +++ b/t/t0018-advice.sh
> @@ -30,4 +30,12 @@ test_expect_success 'advice should not be printed when config variable is set to
> test_must_be_empty actual
> '
>
> +test_expect_success 'advice without the instructions to disable it' '
> + cat >expect <<-\EOF &&
> + hint: This is a piece of advice
> + EOF
> + test-tool -c advice.adviceOff=0 advise "This is a piece of advice" 2>actual &&
> + test_cmp expect actual
> +'
Looking at this test, I wonder why we don't imitate the existing style
of:
test_config advice.adviceOff false &&
test-tool advise "This is a piece of advice" 2>actual &&
test_cmp expect actual
instead of teaching the test-tool helpers how to interpret `-c`
arguments. Doing so would allow us to drop the first couple of patches
in this series and simplify things a bit.
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH 3/3] advice: allow disabling the automatic hint in advise_if_enabled()
From: Junio C Hamano @ 2024-01-09 18:23 UTC (permalink / raw)
To: Rubén Justo; +Cc: Git List
In-Reply-To: <d6099d78-43c6-4709-9121-11f84228cf91@gmail.com>
Rubén Justo <rjusto@gmail.com> writes:
> Using advise_if_enabled() to display an advice will automatically
> include instructions on how to disable the advice, along with the
> main advice:
>
> hint: use --reapply-cherry-picks to include skipped commits
> hint: Disable this message with "git config advice.skippedCherryPicks false"
>
> This can become distracting or noisy over time, while the user may
> still want to receive the main advice.
>
> Let's have a switch to allow disabling this automatic advice.
>
> Signed-off-by: Rubén Justo <rjusto@gmail.com>
> ---
> advice.c | 3 ++-
> advice.h | 3 ++-
> t/t0018-advice.sh | 8 ++++++++
> 3 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/advice.c b/advice.c
> index 50c79443ba..fa203f8806 100644
> --- a/advice.c
> +++ b/advice.c
> @@ -79,6 +79,7 @@ static struct {
> [ADVICE_UPDATE_SPARSE_PATH] = { "updateSparsePath", 1 },
> [ADVICE_WAITING_FOR_EDITOR] = { "waitingForEditor", 1 },
> [ADVICE_WORKTREE_ADD_ORPHAN] = { "worktreeAddOrphan", 1 },
> + [ADVICE_ADVICE_OFF] = { "adviceOff", 1 },
> };
>
> static const char turn_off_instructions[] =
> @@ -93,7 +94,7 @@ static void vadvise(const char *advice, int display_instructions,
>
> strbuf_vaddf(&buf, advice, params);
>
> - if (display_instructions)
> + if (display_instructions && advice_enabled(ADVICE_ADVICE_OFF))
> strbuf_addf(&buf, turn_off_instructions, key);
>
> for (cp = buf.buf; *cp; cp = np) {
> diff --git a/advice.h b/advice.h
> index 2affbe1426..1f2eef034e 100644
> --- a/advice.h
> +++ b/advice.h
> @@ -10,7 +10,7 @@ struct string_list;
> * Add the new config variable to Documentation/config/advice.txt.
> * Call advise_if_enabled to print your advice.
> */
> - enum advice_type {
> +enum advice_type {
> ADVICE_ADD_EMBEDDED_REPO,
> ADVICE_ADD_EMPTY_PATHSPEC,
> ADVICE_ADD_IGNORED_FILE,
> @@ -50,6 +50,7 @@ struct string_list;
> ADVICE_WAITING_FOR_EDITOR,
> ADVICE_SKIPPED_CHERRY_PICKS,
> ADVICE_WORKTREE_ADD_ORPHAN,
> + ADVICE_ADVICE_OFF,
> };
>
> int git_default_advice_config(const char *var, const char *value);
> diff --git a/t/t0018-advice.sh b/t/t0018-advice.sh
> index c13057a4ca..0b6a8b4a10 100755
> --- a/t/t0018-advice.sh
> +++ b/t/t0018-advice.sh
> @@ -30,4 +30,12 @@ test_expect_success 'advice should not be printed when config variable is set to
> test_must_be_empty actual
> '
>
> +test_expect_success 'advice without the instructions to disable it' '
> + cat >expect <<-\EOF &&
> + hint: This is a piece of advice
> + EOF
> + test-tool -c advice.adviceOff=0 advise "This is a piece of advice" 2>actual &&
> + test_cmp expect actual
> +'
This is testing the right thing but in a "showing off a shiny new
toy" way. We want to make sure we will catch regressions in the
future by testing with a bit more conditions perturbed. For
example, with the new "-c var=val" mechanism, we could
* set advice.nestedtag to off (which would disable the whole
advice)
* set advice.adviceoff to on (which should be the same as not
setting it explicitly at all).
to test different combinations that we were unable to test before
[2/3] invented the mechanism.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/3] t/test-tool: handle -c <name>=<value> arguments
From: Taylor Blau @ 2024-01-09 18:20 UTC (permalink / raw)
To: Rubén Justo; +Cc: Git List
In-Reply-To: <6a4d6a56-ab6f-4557-a5a3-1713f57cbfc9@gmail.com>
On Tue, Jan 09, 2024 at 04:29:57PM +0100, Rubén Justo wrote:
> Soon we're going to need to pass configuration values to a command in
> test-tool.
>
> Let's teach test-tool to take config values via command line arguments.
I wasn't expecting a step like this to appear in this series. I don't
have strong feelings about it, especially since test-tool helpers
already understand $GIT_DIR/config when they rely on library code which
implicitly reads configuration.
But it does seem odd to have test-tool invocations that intimately
depend on a particular set of configuration values. At the very least,
this step seems to encourage passing finely tuned configuration values
to test-tool helpers, which I am not sure is a good idea.
Your patch message suggests that this will be useful in the following
patch, which makes sense. But I wonder if it would be easier to avoid
the test-tool entirely and call some Git command in a state that we
expect to generate advice. Then we can test its output with various
values of advice.adviceOff.
> Signed-off-by: Rubén Justo <rjusto@gmail.com>
> ---
> t/helper/test-tool.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
The patch itself looks reasonable, though.
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH 2/3] t/test-tool: handle -c <name>=<value> arguments
From: Junio C Hamano @ 2024-01-09 18:19 UTC (permalink / raw)
To: Rubén Justo; +Cc: Git List
In-Reply-To: <6a4d6a56-ab6f-4557-a5a3-1713f57cbfc9@gmail.com>
Rubén Justo <rjusto@gmail.com> writes:
> Soon we're going to need to pass configuration values to a command in
> test-tool.
>
> Let's teach test-tool to take config values via command line arguments.
>
> Signed-off-by: Rubén Justo <rjusto@gmail.com>
> ---
> t/helper/test-tool.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
Nice.
>
> diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
> index d9f57c20db..7eba4ec9ab 100644
> --- a/t/helper/test-tool.c
> +++ b/t/helper/test-tool.c
> @@ -3,9 +3,10 @@
> #include "test-tool-utils.h"
> #include "trace2.h"
> #include "parse-options.h"
> +#include "config.h"
>
> static const char * const test_tool_usage[] = {
> - "test-tool [-C <directory>] <command> [<arguments>...]]",
> + "test-tool [-C <directory>] [-c <name>=<value>] <command> [<arguments>...]",
> NULL
> };
>
> @@ -106,6 +107,13 @@ static NORETURN void die_usage(void)
> exit(128);
> }
>
> +static int parse_config_option(const struct option *opt, const char *arg,
> + int unset)
> +{
> + git_config_push_parameter(arg);
> + return 0;
> +}
> +
> int cmd_main(int argc, const char **argv)
> {
> int i;
> @@ -113,6 +121,9 @@ int cmd_main(int argc, const char **argv)
> struct option options[] = {
> OPT_STRING('C', NULL, &working_directory, "directory",
> "change the working directory"),
> + OPT_CALLBACK('c', NULL, NULL, "<name>=<value>",
> + "pass a configuration parameter to the command",
> + parse_config_option),
> OPT_END()
> };
^ 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