What's cooking in git.git (Oct 2022, #06; Wed, 19)
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. A topic without enough support may be discarded after a long period of no activity.
Git 2.38.1 and friends that address a couple of CVE on maintenance tracks have been released and they are all merged up to the development branches.
Some topics outside 'next' have been expecting updates for too long and we may want to discard them, unless they see some activities.
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']
* ab/coding-guidelines-c99 (2022-10-11) 5 commits (merged to 'next' on 2022-10-13 at c6b2b74dfb)
+ CodingGuidelines: recommend against unportable C99 struct syntax
+ CodingGuidelines: mention C99 features we can't use
+ CodingGuidelines: allow declaring variables in for loops
+ CodingGuidelines: mention dynamic C99 initializer elements
+ CodingGuidelines: update for C99
Update CodingGuidelines to clarify what features to use and avoid in C99.
source: <[email protected]>
* jh/struct-zero-init-with-older-clang (2022-10-10) 1 commit (merged to 'next' on 2022-10-13 at 393abc3019)
+ config.mak.dev: disable suggest braces error on old clang versions
Work around older clang that warns against C99 zero initialization syntax for struct.
source: <[email protected]>
* rs/archive-dedup-printf (2022-10-11) 1 commit
(merged to 'next' on 2022-10-13 at af770cf00f)
+ archive: deduplicate verbose printing
Code simplification.
source: <[email protected]>
--------------------------------------------------
[New Topics]
* jk/unused-anno-more (2022-10-17) 12 commits
- ll-merge: mark unused parameters in callbacks
- diffcore-pickaxe: mark unused parameters in pickaxe functions
- convert: mark unused parameter in null stream filter
- apply: mark unused parameters in noop error/warning routine
- apply: mark unused parameters in handlers
- date: mark unused parameters in handler functions
- string-list: mark unused callback parameters
- object-file: mark unused parameters in hash_unknown functions
- mark unused parameters in trivial compat functions
- update-index: drop unused argc from do_reupdate()
- submodule--helper: drop unused argc from module_list_compute()
- diffstat_consume(): assert non-zero length
More UNUSED annotation to help using -Wunused option with the compiler.
Will merge to 'next'.
source: <[email protected]>
* tb/save-keep-pack-during-geometric-repack (2022-10-17) 1 commit
- repack: don't remove .keep packs with --pack-kept-objects
When geometric repacking feature is in use together with the --pack-kept-objects option, we lost packs marked with .keep files.
Will merge to 'next'.
source: <6a012cd625c1d197ede91c85299cbfb37adf356b.1666059872.git.me@ttaylorr.com>
* mm/git-pm-try-catch-syntax-fix (2022-10-17) 1 commit
- Git.pm: add semicolon after catch statement
Fix a longstanding syntax error in Git.pm error codepath.
Will merge to 'next'??
source: <[email protected]>
* ab/macos-build-fix-with-sha1dc (2022-10-19) 1 commit (merged to 'next' on 2022-10-19 at 408ce79f33)
+ fsmonitor OSX: compile with DC_SHA1=YesPlease
Enable macOS build with sha1dc hash function.
Will merge to 'master'.
source: <[email protected]>
* jk/use-o0-in-leak-sanitizer (2022-10-19) 1 commit (merged to 'next' on 2022-10-19 at 27c2546b98)
+ Makefile: force -O0 when compiling with SANITIZE=leak
Avoid false-positive from LSan whose assumption may be broken with higher optimization levels.
Will merge to 'master'.
source: <[email protected]>
* jr/embargoed-releases-doc (2022-10-19) 1 commit
- embargoed releases: also describe the git-security list and the process
The role the security mailing list plays in an embargoed release has been documented.
Will merge to 'next'?
source: <[email protected]>
--------------------------------------------------
[Stalled]
* ag/merge-strategies-in-c (2022-08-10) 14 commits
- sequencer: use the "octopus" strategy without forking
- sequencer: use the "resolve" strategy without forking
- merge: use the "octopus" strategy without forking
- merge: use the "resolve" strategy without forking
- merge-octopus: rewrite in C
- merge-recursive: move better_branch_name() to merge.c
- merge-resolve: rewrite in C
- merge-one-file: rewrite in C
- update-index: move add_cacheinfo() to read-cache.c
- merge-index: add a new way to invoke `git-merge-one-file'
- merge-index: drop the index
- merge-index: libify merge_one_path() and merge_all()
- t6060: add tests for removed files
- t6060: modify multiple files to expose a possible issue with merge-index
An attempt to rewrite remaining merge strategies from shell to C.
Needs more work.
At the minimum, we should lose 11/14 and possibly 08/14. cf. <[email protected]>
source: <[email protected]>
* po/glossary-around-traversal (2022-07-09) 3 commits
- glossary: add reachability bitmap description
- glossary: add commit graph description
- glossary: add Object DataBase (ODB) abbreviation
The glossary entries for "commit-graph file" and "reachability bitmap" have been added.
Expecting a reroll.
cf. <[email protected]>
source: <[email protected]>
* gc/submodule-clone-update-with-branches (2022-08-29) 6 commits
- clone, submodule update: check out branches
- submodule--helper: refactor up-to-date criterion
- submodule: return target of submodule symref
- t5617: drop references to remote-tracking branches
- repo-settings: add submodule_propagate_branches
- clone: teach --detach option
"git clone --recurse-submodules" and "git submodule update" learns to honor the "propagete branches" option.
Expecting a reroll.
cf. <[email protected]> and others
source: <[email protected]>
* tb/diffstat-with-utf8-strwidth (2022-09-14) 1 commit
- diff.c: use utf8_strwidth() to count display width
"git diff --stat" etc. were invented back when everything was ASCII and strlen() was a way to measure the display width of a string; adjust them to compute the display width assuming UTF-8 pathnames.
Expecting a reroll.
source: <[email protected]>
* mj/credential-helper-auth-headers (2022-09-13) 8 commits
- http: set specific auth scheme depending on credential
- http: move proactive auth to first slot creation
- http: store all request headers on active_request_slot
- credential: add WWW-Authenticate header to cred requests
- http: read HTTP WWW-Authenticate response headers
- osxkeychain: clarify that we ignore unknown lines
- netrc: ignore unknown lines (do not die)
- wincred: ignore unknown lines (do not die)
Extending credential helper protocol.
Expecting a reroll.
A separate non-RFC submission of the first three is expected.
cf. <AS8PR03MB86897FAC3E1E4F03D4420644C04F9@AS8PR03MB8689.eurprd03.prod.outlook.com>
source: <[email protected]>
* cw/submodule-status-in-parallel (2022-09-23) 4 commits . diff-lib: parallelize run_diff_files for submodules . diff-lib: refactor functions
. submodule: move status parsing into function . run-command: add pipe_output to run_processes_parallel
Allow the internal "diff-files" engine to run "how has this submodule changed?" in parallel to speed up "git status".
Breaks its self check.
cf. https://github.com/git/git/actions/runs/3115673002/jobs/5052804463
source: <[email protected]>
* es/mark-gc-cruft-as-experimental (2022-08-03) 2 commits
- config: let feature.experimental imply gc.cruftPacks=true
- gc: add tests for --cruft and friends
Enable gc.cruftpacks by default for those who opt into feature.experimental setting.
Expecting a reroll.
cf. <[email protected]> cf. <[email protected]>
source: <[email protected]>
* es/doc-creation-factor-fix (2022-07-28) 2 commits
- range-diff: clarify --creation-factor=<factor>
- format-patch: clarify --creation-factor=<factor>
Expecting a reroll by somebody more familiar with the logic cf. <[email protected]>
source: <[email protected]>
* cw/remote-object-info (2022-08-13) 7 commits . SQUASH???
. cat-file: add remote-object-info to batch-command . transport: add client support for object-info . serve: advertise object-info feature
. protocol-caps: initialization bug fix
. fetch-pack: move fetch initialization
. fetch-pack: refactor packet writing
A client component to talk with the object-info endpoint.
Expecting a reroll.
Under SANITIZE=address, t1006-cat-file.sh finds a breakage. cf. <[email protected]>
cf. <CAFySSZDvgwbbHCHfyuaqX3tKsr-GjJ9iihygg6rNNe46Ys7_EA@mail.gmail.com>
source: <[email protected]>
--------------------------------------------------
[Cooking]
* js/cmake-updates (2022-10-19) 5 commits
- cmake: increase time-out for a long-running test
- cmake: avoid editing t/test-lib.sh
- add -p: avoid ambiguous signed/unsigned comparison
- cmake: copy the merge tools for testing
- cmake: make it easier to diagnose regressions in CTest runs
Update to build procedure with VS using CMake/CTest.
Will merge to 'next'?
source: <[email protected]>
* gc/bare-repo-discovery (2022-10-13) 1 commit
(merged to 'next' on 2022-10-17 at 3de2be7c14)
+ config: respect includes in protected config
Allow configuration files in "protected" scopes to include other configuration files.
Will merge to 'master'.
source: <[email protected]>
* jh/trace2-timers-and-counters (2022-10-13) 7 commits
- trace2: add global counter mechanism
- trace2: add stopwatch timers
- trace2: convert ctx.thread_name from strbuf to pointer
- trace2: rename the thread_name argument to trace2_thread_start
- api-trace2.txt: elminate section describing the public trace2 API
- tr2tls: clarify TLS terminology
- trace2: use size_t alloc,nr_open_regions in tr2tls_thread_ctx
Two new facilities, "timer" and "counter", are introduced to the trace2 API.
source: <[email protected]>
* tb/midx-bitmap-selection-fix (2022-10-13) 4 commits
- pack-bitmap-write.c: instrument number of reused bitmaps
- midx.c: instrument MIDX and bitmap generation with trace2 regions
- midx.c: consider annotated tags during bitmap selection
- midx.c: fix whitespace typo
A bugfix with tracing support in midx codepath
Will merge to 'next'.
source: <[email protected]>
* tb/remove-unused-pack-bitmap (2022-10-17) 1 commit
- builtin/repack.c: remove redundant pack-based bitmaps
When creating a multi-pack bitmap, remove per-pack bitmap files unconditionally as they will never be consulted.
Will merge to 'next'?
source: <1e0ef7ee7ff5feb323c77e594cd65433fb1d99f7.1666061096.git.me@ttaylorr.com>
* nw/t1002-cleanup (2022-10-14) 1 commit
- t1002: modernize outdated conditional
Code clean-up in test.
Will merge to 'next'.
source: <[email protected]>
* zh/patch-id (2022-10-14) 7 commits
- documentation: format-patch: clarify requirements for patch-ids to match
- builtin: patch-id: remove unused diff-tree prefix
- builtin: patch-id: add --include-whitespace as a command mode
- patch-id: fix patch-id for mode changes
- builtin: patch-id: fix patch-id with binary diffs
- patch-id: use stable patch-id for rebases
- patch-id: fix stable patch id for binary / header-only
A new "--include-whitespace" option is added to "git patch-id", and existing bugs in the internal patch-id logic that did not match what "git patch-id" produces have been corrected.
Will merge to 'next'?
source: <[email protected]>
* hl/archive-recursive (2022-10-19) 10 commits
- fixup! archive: add tests for git archive --recurse-submodules
- archive: add tests for git archive --recurse-submodules
- archive: add --recurse-submodules to git-archive command
- archive: remove global repository from archive_args
- archive: pass repo objects to write_archive handlers
- tree: add repository parameter to read_tree_fn_t
- tree: handle submodule case for read_tree_at properly
- tree: increase test coverage for tree.c
- tree: update cases to use repo_ tree methods
- tree: do not use the_repository for tree traversal methods.
"git archive" has been taught "--recurse-submodules" option to create a tarball that includes contents from submodules.
Expecting a reroll.
source: <[email protected]>
* pw/rebase-keep-base-fixes (2022-10-17) 8 commits
- rebase --keep-base: imply --no-fork-point
- rebase --keep-base: imply --reapply-cherry-picks
- rebase: factor out branch_base calculation
- rebase: rename merge_base to branch_base
- rebase: store orig_head as a commit
- rebase: be stricter when reading state files containing oids
- t3416: set $EDITOR in subshell
- t3416: tighten two tests
(this branch is used by pw/rebase-reflog-fixes.)
"git rebase --keep-base" used to discard the commits that are already cherry-picked to the upstream, even when "keep-base" meant that the base, on top of which the history is being rebuilt, does not yet include these cherry-picked commits. The --keep-base option now implies --reapply-cherry-picks and --no-fork-point options.
Will merge to 'next'??
source: <[email protected]>
* ab/grep-simplify-extended-expression (2022-10-11) 1 commit (merged to 'next' on 2022-10-13 at 07993f09bc)
+ grep.c: remove "extended" in favor of "pattern_expression", fix segfault
Giving "--invert-grep" and "--all-match" without "--grep" to the "git log" command resulted in an attempt to access grep pattern expression structure that has not been allocated, which has been corrected.
Will merge to 'master'.
source: <[email protected]>
* pw/rebase-reflog-fixes (2022-10-17) 9 commits
- rebase: cleanup action handling
- rebase --abort: improve reflog message
- rebase --apply: make reflog messages match rebase --merge
- rebase --apply: respect GIT_REFLOG_ACTION
- rebase --merge: fix reflog message after skipping
- rebase --merge: fix reflog when continuing
- t3406: rework rebase reflog tests
- rebase --apply: remove duplicated code
- Merge branch 'pw/rebase-keep-base-fixes' into pw/rebase-reflog-fixes (this branch uses pw/rebase-keep-base-fixes.)
Fix some bugs in the reflog messages when rebasing and changes the reflog messages of "rebase --apply" to match "rebase --merge" with the aim of making the reflog easier to parse.
Will merge to 'next'??
source: <[email protected]>
* sd/doc-smtp-encryption (2022-10-12) 1 commit
- docs: git-send-email: difference between ssl and tls smtp-encryption
Expecting a reroll??
cf. <[email protected]>
source: <[email protected]>
* jc/symbolic-ref-no-recurse (2022-10-09) 1 commit (merged to 'next' on 2022-10-13 at 532a3f6a5f)
+ symbolic-ref: teach "--[no-]recurse" option
After checking out a "branch" that is a symbolic-ref that points at another branch, "git symbolic-ref HEAD" reports the underlying branch, not the symbolic-ref the user gave checkout as argument. The command learned the "--no-recurse" option to stop after dereferencing a symbolic-ref only once.
Will merge to 'master'.
source: <[email protected]>
* ds/cmd-main-reorder (2022-10-08) 1 commit
(merged to 'next' on 2022-10-14 at d7f07dbecf)
+ git.c: improve code readability in cmd_main()
Code clean-up.
Will merge to 'master'.
source: <[email protected]>
* ed/fsmonitor-inotify (2022-10-14) 7 commits
. fsmonitor: update doc for Linux
. fsmonitor: test updates
. fsmonitor: enable fsmonitor for Linux
. fsmonitor: implement filesystem change listener for Linux
. fsmonitor: determine if filesystem is local or remote
. fsmonitor: prepare to share code between Mac OS and Linux
. Merge branch 'ed/fsmonitor-on-networked-macos' into ed/fsmonitor-inotify
Bundled fsmonitor for Linux using inotify API.
Needs review.
Occasional breakages of t7527.16?
source: <[email protected]>
* en/sparse-checkout-design (2022-10-08) 1 commit
- sparse-checkout.txt: new document with sparse-checkout directions
Design doc.
Needs review.
source: <[email protected]>
* jc/more-sanitizer-at-ci (2022-10-11) 1 commit
. ci: add address and undefined sanitizer tasks
Enable address and undefined sanitizer tasks at GitHub Actions CI.
With this p4 tests seem to die with the server side going away.
source: <[email protected]>
* od/ci-use-checkout-v3-when-applicable (2022-10-10) 2 commits . ci(main): linux32 uses actions/checkout@v2
. ci(main): upgrade actions/checkout to v3
Attempt to update GitHub CI to use actions/checkout@v3
Expecting a reroll.
Seems to break the CI completely.
source: <[email protected]>
* ab/run-hook-api-cleanup (2022-10-12) 15 commits
- run-command.c: remove "max_processes", add "const" to signal() handler
- run-command.c: pass "opts" further down, and use "opts->processes"
- run-command.c: use "opts->processes", not "pp->max_processes"
- run-command.c: don't copy "data" to "struct parallel_processes"
- run-command.c: don't copy "ungroup" to "struct parallel_processes"
- run-command.c: don't copy *_fn to "struct parallel_processes"
- run-command.c: make "struct parallel_processes" const if possible
- run-command API: move *_tr2() users to "run_processes_parallel()"
- run-command API: have run_process_parallel() take an "opts" struct
- run-command.c: use designated init for pp_init(), add "const"
- run-command API: don't fall back on online_cpus()
- run-command API: make "n" parameter a "size_t"
- run-command tests: use "return", not "exit"
- run-command API: have "run_processes_parallel{,_tr2}()" return void
- run-command test helper: use "else if" pattern
Move a global variable added as a hack during regression fixes to its proper place in the API.
Will merge to 'next'.
source: <[email protected]>
* pw/test-todo (2022-10-06) 3 commits
- test_todo: allow [verbose] test as the command
- test_todo: allow [!] grep as the command
- tests: add test_todo() to mark known breakages
RFC for test framework improvement.
Needs review.
source: <[email protected]>
* rj/branch-edit-description-with-nth-checkout (2022-10-10) 1 commit (merged to 'next' on 2022-10-14 at 90850a2211)
+ branch: support for shortcuts like @{-1}, completed
"git branch --edit-description @{-1}" is now a way to edit branch description of the branch you were on before switching to the current branch.
Will merge to 'master'.
source: <[email protected]>
* rs/diff-caret-bang-with-parents (2022-10-01) 3 commits (merged to 'next' on 2022-10-17 at 24609eb777)
+ diff: support ^! for merges
+ revisions.txt: unspecify order of resolved parts of ^!
+ revision: use strtol_i() for exclude_parent
"git diff rev^!" did not show combined diff to go to the rev from its parents.
Will merge to 'master'.
source: <[email protected]>
* ab/doc-synopsis-and-cmd-usage (2022-10-13) 34 commits
- tests: assert consistent whitespace in -h output
- tests: start asserting that *.txt SYNOPSIS matches -h output
- doc txt & -h consistency: make "worktree" consistent
- worktree: define subcommand -h in terms of command -h
- reflog doc: list real subcommands up-front
- doc txt & -h consistency: make "commit" consistent
- doc txt & -h consistency: make "diff-tree" consistent
- doc txt & -h consistency: use "[<label>...]" for "zero or more"
- doc txt & -h consistency: make "annotate" consistent
- doc txt & -h consistency: make "stash" consistent
- doc txt & -h consistency: add missing options
- doc txt & -h consistency: use "git foo" form, not "git-foo"
- doc txt & -h consistency: make "bundle" consistent
- doc txt & -h consistency: make "read-tree" consistent
- doc txt & -h consistency: make "rerere" consistent
- doc txt & -h consistency: add missing options and labels
- doc txt & -h consistency: make output order consistent
- doc txt & -h consistency: add or fix optional "--" syntax
- doc txt & -h consistency: fix mismatching labels
- doc SYNOPSIS & -h: use "-" to separate words in labels, not "_"
- doc txt & -h consistency: use "<options>", not "<options>..."
- stash doc SYNOPSIS & -h: correct padding around "[]()"
- doc txt & -h consistency: correct padding around "[]()"
- doc txt & -h consistency: balance unbalanced "[" and "]"
- doc txt & -h consistency: add "-z" to cat-file "-h"
- doc txt & -h consistency: fix incorrect alternates syntax
- doc txt & -h consistency: word-wrap
- built-ins: consistently add "\n" between "usage" and options
- doc SYNOPSIS: consistently use ' for commands
- doc SYNOPSIS: don't use ' for subcommands
- bundle: define subcommand -h in terms of command -h
- builtin/bundle.c: indent with tabs
- CodingGuidelines: update and clarify command-line conventions
- tests: assert *.txt SYNOPSIS and -h output
The short-help text shown by "git cmd -h" and the synopsis text shown at the beginning of "git help cmd" have been made more consistent.
Will merge to 'next'?
source: <[email protected]>
* ab/coccicheck-incremental (2022-10-14) 11 commits
- spatchcache: add a ccache-alike for "spatch"
- cocci: run against a generated ALL.cocci
- cocci: optimistically use COMPUTE_HEADER_DEPENDENCIES
- cocci: make "coccicheck" rule incremental
- cocci: split off "--all-includes" from SPATCH_FLAGS
- cocci: split off include-less "tests" from SPATCH_FLAGS
- Makefile: split off SPATCH_BATCH_SIZE comment from "cocci" heading
- Makefile: have "coccicheck" re-run if flags change
- Makefile: add ability to TAB-complete cocci *.patch rules
- cocci rules: remove unused "F" metavariable from pending rule
- Makefile + shared.mak: rename and indent $(QUIET_SPATCH_T)
"make coccicheck" is time consuming. It has been made to run more incrementally.
Will merge to 'next'?
source: <[email protected]>
* ds/bundle-uri-3 (2022-10-12) 13 commits
- bundle-uri: suppress stderr from remote-https
- bundle-uri: quiet failed unbundlings
- bundle: add flags to verify_bundle()
- bundle-uri: fetch a list of bundles
- bundle: properly clear all revision flags
- bundle-uri: limit recursion depth for bundle lists
- bundle-uri: parse bundle list in config format
- bundle-uri: unit test "key=value" parsing
- bundle-uri: create "key=value" line parsing
- bundle-uri: create base key-value pair parsing
- bundle-uri: create bundle_list struct and helpers
- bundle-uri: use plain string in find_temp_filename()
- Merge branch 'ds/bundle-uri-clone' into ds/bundle-uri-3
Define the logical elements of a "bundle list", data structure to store them in-core, format to transfer them, and code to parse them.
source: <[email protected]>
* js/bisect-in-c (2022-08-30) 17 commits
- bisect: no longer try to clean up left-over .git/head-name files
- bisect: remove Cogito-related code
- Turn git bisect into a full built-in
- bisect: move even the command-line parsing to bisect--helper
- bisect--helper: make state optional
- bisect--helper: calling bisect_state() without an argument is a bug
- bisect: avoid double-quoting when printing the failed command
- bisect run: fix the error message
- bisect: verify that a bogus option won't try to start a bisection
- bisect--helper: migrate to OPT_SUBCOMMAND()
- bisect--helper: make the order consistently argc, argv
- bisect--helper: make terms an explicit singleton
- bisect--helper: simplify exit code computation
- bisect--helper: really retire --bisect-autostart
- bisect--helper: really retire --bisect-next-check
- bisect--helper: retire the --no-log option
- Merge branch 'sg/parse-options-subcommand' into js/bisect-in-c
Final bits of "git bisect.sh" have been rewritten in C.
Needs review.
cf. <[email protected]>
source: <[email protected]>
Quoted 9 lines · Junio C Hamano
* jk/use-o0-in-leak-sanitizer (2022-10-19) 1 commit (merged to 'next' on 2022-10-19 at
27c2546b98)
+Makefile: force -O0 when compiling with SANITIZE=leakAvoid false-positive from LSan whose assumption may be broken with higher optimization levels.
Will merge to 'master'.
source: <[email protected]>
BTW, you should be able to see that "next" now passes the leaks CI job (because of this patch), but master doesn't yet.
-Peff
Quoted 6 lines · Jeff King
Quoted 4 lines · Junio C Hamano
* jk/use-o0-in-leak-sanitizer (2022-10-19) 1 commit (merged to 'next' on 2022-10-19 at
27c2546b98)
+Makefile: force -O0 when compiling with SANITIZE=leak
Quoted 8 lines
Quoted 5 lines
Avoid false-positive from LSan whose assumption may be broken with higher optimization levels.
Will merge to 'master'.
source: <[email protected]>BTW, you should be able to see that "next" now passes the leaks CI job (because of this patch), but master doesn't yet.
Yup, thanks!
Unfortunately, without some CI/make updates, we cannot verify that macOS builds are green again without Apple Crypto X-<.
pw/rebase-reflog-fixes (was Re: What's cooking in git.git (Oct 2022, #06; Wed, 19))
In reply to Junio C HamanoHi Junio
Quoted 12 lines
* pw/rebase-reflog-fixes (2022-10-17) 9 commits
- rebase: cleanup action handling
- rebase --abort: improve reflog message
- rebase --apply: make reflog messages match rebase --merge
- rebase --apply: respectGIT_REFLOG_ACTION
- rebase --merge: fix reflog message after skipping
- rebase --merge: fix reflog when continuing
- t3406: rework rebase reflog tests
- rebase --apply: remove duplicated code
- Merge branch 'pw/rebase-keep-base-fixes' into pw/rebase-reflog-fixes (this branch uses pw/rebase-keep-base-fixes.)
Quoted 6 lines
Fix some bugs in the reflog messages when rebasing and changes the reflog messages of "rebase --apply" to match "rebase --merge" with the aim of making the reflog easier to parse.
Will merge to 'next'??
source: <[email protected]>
Can you hold off on this one please, I'm planning to re-roll next week to address <[email protected]>
Thanks
Phillip
Quoted 7 lines
*
mm/git-pm-try-catch-syntax-fix(2022-10-17) 1 commit
- Git.pm: add semicolon after catch statementFix a longstanding syntax error in Git.pm error codepath.
Will merge to 'next'??
source: <[email protected]>
I am not totally sure what these question marks mean, but I'm happy for this to go to next, for what it's worth. (There was an outstanding question about the general behavior of Git.pm in bare unsafe repositories, but I certainly am not planning to solve it in this series.) Thanks!
Signature · 2 lines
Michael McClimon [email protected]
Quoted 5 lines · Michael McClimon
Quoted 5 lines
*
mm/git-pm-try-catch-syntax-fix(2022-10-17) 1 commit
- Git.pm: add semicolon after catch statementFix a longstanding syntax error in Git.pm error codepath.
Quoted 8 lines
Quoted 2 lines
Will merge to 'next'??
source: <[email protected]>I am not totally sure what these question marks mean, but I'm happy for this to go to next, for what it's worth. (There was an outstanding question about the general behavior of Git.pm in bare unsafe repositories, but I certainly am not planning to solve it in this series.) Thanks!
Me too. I had hoped for a test, but because of those outstanding questions about the behavior, I think we are better off skipping it for now, and fixing what is obviously a bug.
There is one devil's advocate thing that is nagging at me, though. Because this whole safe-directory thing is security-relevant, could we make things worse by "fixing" it partially? That is, consider this code:
git init --bare foo.git sudo chown -R nobody foo.git cd foo.git perl -MGit -e 'Git->repository'
Post 2.35.4, etc, is it a security vulnerability for that final step to open the repository? If so, then right now we are "not vulnerable" in the sense that an unrelated bug causes Git.pm to bail in the final step. And fixing that will mean we become vulnerable.
To be clear, having an unrelated bug is not a good way to prevent security vulnerabilities. But it is the status quo. If the fixed version (after your patch to add the semicolon) is vulnerable, but the released one in the hands of users is not, then fixing it does make things worse in the short term (even though the obviously correct thing in the long run is to fix that bug and also correct the vulnerability the right way).
I wasn't around when the directory-ownership stuff was discussed or worked on. But it might be nice for people who worked on it or thought a lot about it to give an opinion on whether the state after your patch is in fact vulnerable to a security flaw.
-Peff
Quoted 43 lines · Jeff King
Quoted 5 lines · Michael McClimon
Quoted 5 lines
*
mm/git-pm-try-catch-syntax-fix(2022-10-17) 1 commit
- Git.pm: add semicolon after catch statementFix a longstanding syntax error in Git.pm error codepath.
Quoted 8 lines
Quoted 2 lines
Will merge to 'next'??
source: <[email protected]>I am not totally sure what these question marks mean, but I'm happy for this to go to next, for what it's worth. (There was an outstanding question about the general behavior of Git.pm in bare unsafe repositories, but I certainly am not planning to solve it in this series.) Thanks!
Me too. I had hoped for a test, but because of those outstanding questions about the behavior, I think we are better off skipping it for now, and fixing what is obviously a bug.
There is one devil's advocate thing that is nagging at me, though. Because this whole safe-directory thing is security-relevant, could we make things worse by "fixing" it partially? That is, consider this code:
git init --bare foo.git sudo chown -R nobody foo.git cd foo.git perl -MGit -e 'Git->repository'Post 2.35.4, etc, is it a security vulnerability for that final step to open the repository? If so, then right now we are "not vulnerable" in the sense that an unrelated bug causes Git.pm to bail in the final step. And fixing that will mean we become vulnerable.
To be clear, having an unrelated bug is not a good way to prevent security vulnerabilities. But it is the status quo. If the fixed version (after your patch to add the semicolon) is vulnerable, but the released one in the hands of users is not, then fixing it does make things worse in the short term (even though the obviously correct thing in the long run is to fix that bug and also correct the vulnerability the right way).
Quoted 4 lines
I wasn't around when the directory-ownership stuff was discussed or worked on. But it might be nice for people who worked on it or thought a lot about it to give an opinion on whether the state after your patch is in fact vulnerable to a security flaw.
Off the top of my mind, the safe.* protections mitigate:
1) safe.directory: Attacker creates a difficult-to-spot repo high in the directory structure in a shared machine, and the victim navigates into an innocuous-looking directory that happens to be a subdirectory of that repo.
2) safe.directory: Attacker creates a repo somewhere on a shared machine and tricks the victim into navigating into that repo.
3) safe.bareRepository: Attacker creates a repo with a bare repo in its working tree and tricks the victim into cloning the repo and navigating into the bare repo.
In each of these cases, having the user specify GIT_DIR to mean "yes this directory is really the one I wanted" is a reasonable tradeoff IMO. Some ways of setting GIT_DIR might be ok, e.g. GIT_DIR=. everywhere is pretty flawed for 2 and 3, but it does mitigate against 1 (which is arguably the scariest).
However, if GIT_DIR is set by searching for the repo (e.g. by "git rev-parse --git-dir"), this just disables every safe.* protection. IIRC, you mentioned that this is exactly what Git.pm does, so as it is, yes this does leave us in a vulnerable state.
If we are using git rev-parse --git-dir, maybe a reasonable solution would be to teach rev-parse to respect safe.* protections? e.g. git rev-parse --git-dir --safe could error out just like git in an unsafe repository.
[1] https://lore.kernel.org/git/[email protected]
Quoted 2 lines
-Peff
Quoted 4 lines · Glen Choo
However, if
GIT_DIRis set by searching for the repo (e.g. by "git rev-parse --git-dir"), this just disables every safe.* protection. IIRC, you mentioned that this is exactly what Git.pm does, so as it is, yes this does leave us in a vulnerable state.
Thanks, that matches my understanding. I think Git.pm is vulnerable (but again, not in a released version because of the syntax error).
Quoted 4 lines
If we are using
git rev-parse --git-dir, maybe a reasonable solution would be to teachrev-parseto respect safe.* protections? e.g.git rev-parse --git-dir --safecould error out just likegitin an unsafe repository.
rev-parse does work that way. It's just that Git.pm has some oddities. More discussion (with my analysis and a patch) in this other thread:
https://lore.kernel.org/git/[email protected]/
-Peff
tb/remove-unused-pack-bitmap
In reply to Junio C HamanoQuoted 8 lines · Junio C Hamano
* tb/remove-unused-pack-bitmap (2022-10-17) 1 commit
-builtin/repack.c: remove redundant pack-based bitmapsWhen creating a multi-pack bitmap, remove per-pack bitmap files unconditionally as they will never be consulted.
Will merge to 'next'?
source: <1e0ef7ee7ff5feb323c77e594cd65433fb1d99f7.1666061096.git.me@ttaylorr.com>
Yeah, this one is ready to go, per Peff's review:
https://lore.kernel.org/git/[email protected]/
Thanks,
Taylor