git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* What's cooking in git.git (Apr 2022, #03; Tue, 12)
@ 2022-04-12 17:04 Junio C Hamano
  2022-04-12 17:52 ` Philippe Blain
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Junio C Hamano @ 2022-04-12 17:04 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',
which means nothing more than that I have found them of interest for
some reason (like "it may have hard-to-resolve conflicts with
another topic already in flight" or "this may turn out to be
useful").  Do not read too much into a topic being in (or not in)
'seen'.  The ones marked with '.' do not appear in any of the
integration branches, but I am still holding onto them.

Security releases for the 2.30-2.35 maintenance tracks have been
tagged to address CVE-2022-24765, which allows a user to trick other
users into running a command of their choice easily on multi-user
machines with a shared "mob" directory.  The fix has been also
merged to Git 2.36-rc2 and to all integration branches.

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']

* ja/i18n-fix-for-2.36 (2022-04-11) 1 commit
  (merged to 'next' on 2022-04-11 at 0953a117dc)
 + i18n: fix some badly formatted i18n strings

 Fixes to some localizable strings.
 source: <pull.1212.git.1649705011178.gitgitgadget@gmail.com>

--------------------------------------------------
[New Topics]

* pw/test-malloc-with-sanitize-address (2022-04-11) 1 commit
 - tests: make SANITIZE=address imply TEST_NO_MALLOC_CHECK

 Avoid problems from interaction between malloc_check and address
 sanitizer.

 Will merge to 'next'.
 source: <pull.1210.git.1649507317350.gitgitgadget@gmail.com>


* rs/t7812-pcre2-ws-bug-test (2022-04-11) 1 commit
 - t7812: test PCRE2 whitespace bug

 A test to ensure workaround for an earlier pcre2 bug does work.

 Will merge to 'next'.
 source: <3a49649d-8ff9-e5a7-e3fd-33fee5068ae8@web.de>

--------------------------------------------------
[Stalled]

* ab/commit-plug-leaks (2022-02-16) 2 commits
 - commit: use strbuf_release() instead of UNLEAK()
 - commit: fix "author_ident" leak

 Leakfixes in the top-level called-once function.

 Expecting a reroll.
 I think UNLEAK->strbuf_release() is a regression.
 source: <cover-0.2-00000000000-20220216T081844Z-avarab@gmail.com>


* dl/prompt-pick-fix (2022-03-25) 1 commit
 . git-prompt: fix sequencer/todo detection

 Fix shell prompt script (in contrib/) for those who set
 rebase.abbreviateCommands; we failed to recognize that we were in a
 multi-step cherry-pick session.

 Is this even needed?  How?
 cf. <xmqqwngdzque.fsf@gitster.g>
 source: <20220325145301.3370-1-danny0838@gmail.com>


* es/superproject-aware-submodules (2022-03-09) 3 commits
 . rev-parse: short-circuit superproject worktree when config unset
 . introduce submodule.hasSuperproject record
 . t7400-submodule-basic: modernize inspect() helper

 A configuration variable in a repository tells if it is (or is not)
 a submodule of a superproject.

 Expecting a reroll.
 cf. <kl6l4k45s7cb.fsf@chooglen-macbookpro.roam.corp.google.com>
 source: <20220310004423.2627181-1-emilyshaffer@google.com>


* cw/remote-object-info (2022-03-30) 5 commits
 . fixup! transfer.advertiseObjectInfo: add object-info config
 . fixup! object-info: add option for retrieving object info
 . object-info: add option for retrieving object info
 . transfer.advertiseObjectInfo: add object-info config
 . fetch-pack: refactor packet writing and fetch options

 Attempt to add a client component to talk with object-info
 endpoint.

 Expecting a reroll.
 source: <20220328191112.3092139-1-calvinwan@google.com>

--------------------------------------------------
[Cooking]

* ah/convert-warning-message (2022-04-08) 1 commit
 - convert: clarify line ending conversion warning

 Update a few end-user facing messages around eol conversion.

 Will merge to 'next'.
 source: <20220408044154.9947-1-alexhenrie24@gmail.com>


* cg/vscode-with-gdb (2022-04-08) 1 commit
 - contrib/vscode/: debugging with VS Code and gdb

 VS code configuration updates.

 Will merge to 'next'.
 source: <20220407204001.112287-2-cogoni.guillaume@gmail.com>


* gf/unused-includes (2022-04-06) 2 commits
 - apply.c: remove unnecessary include
 - serve.c: remove unnecessary include

 Remove unused includes.

 Will merge to 'next'.
 source: <20220331194436.58005-1-garrit@slashdev.space>


* km/t3501-use-test-helpers (2022-04-06) 1 commit
 - t3501: remove test -f and stop ignoring git <cmd> exit code

 Test script updates.

 Will merge to 'next'.
 source: <20220405134742.17526-2-khalid.masum.92@gmail.com>


* pb/submodule-recurse-mode-enum (2022-04-06) 1 commit
 - submodule.h: use a named enum for RECURSE_SUBMODULES_*

 Small code clean-up.

 Will merge to 'next'.
 source: <pull.1111.v2.git.1649092211419.gitgitgadget@gmail.com>


* rs/commit-summary-wo-break-rewrite (2022-04-06) 1 commit
 - commit, sequencer: turn off break_opt for commit summary

 The commit summary shown after making a commit is matched to what
 is given in "git status" not to use the break-rewrite heuristics.

 Will merge to 'next'.
 source: <c35bd0aa-2e46-e710-2b39-89f18bad0097@web.de>


* tk/p4-utf8-bom (2022-04-06) 1 commit
 - git-p4: preserve utf8 BOM when importing from p4 to git

 "git p4" update.

 Will merge to 'next'.
 source: <pull.1203.git.1649051436934.gitgitgadget@gmail.com>


* tk/p4-with-explicity-sync (2022-04-06) 1 commit
 - git-p4: support explicit sync of arbitrary existing git-p4 refs

 "git p4" update.

 Will merge to 'next'.
 source: <pull.1202.git.1649049054600.gitgitgadget@gmail.com>


* ab/env-array (2022-04-06) 3 commits
 - run-command API users: use "env" not "env_array" in comments & names
 - run-command API: rename "env_array" to "env"
 - cocci: add a rename of "struct child_process"'s "env_array" to "env"

 Rename .env_array member to .env in the child_process structure.

 On hold.
 source: <cover-0.3-00000000000-20220406T104134Z-avarab@gmail.com>


* ab/misc-cleanup (2022-04-01) 6 commits
  (merged to 'next' on 2022-04-04 at c5fb674865)
 + alloc.[ch]: remove alloc_report() function
 + object-store.h: remove unused has_sha1_file*()
 + pack-bitmap-write: remove unused bitmap_reset() function
 + xdiff/xmacros.h: remove unused XDL_PTRFREE
 + configure.ac: remove USE_PIC comment
 + run-command.h: remove always unused "clean_on_exit_handler_cbdata"

 Code clean-up.

 Will cook in 'next'.
 source: <cover-v4-0.6-00000000000-20220331T014349Z-avarab@gmail.com>


* gf/shorthand-version-and-help (2022-03-31) 1 commit
 - cli: add -v and -h shorthands

 "git -v" and "git -h" are now understood as "git --version" and
 "git --help".

 Will merge to 'next'.
 source: <20220331212709.36036-1-garrit@slashdev.space>


* ea/progress-partial-blame (2022-04-06) 1 commit
  (merged to 'next' on 2022-04-07 at 7df8392d71)
 + blame: report correct number of lines in progress when using ranges

 The progress meter of "git blame" was showing incorrect numbers
 when processing only parts of the file.

 Will cook in 'next'.
 source: <20220406181320.16911-1-eantoranz@gmail.com>


* ab/plug-leak-in-revisions (2022-04-03) 28 commits
 - revisions API: add a TODO for diff_free(&revs->diffopt)
 - revisions API: have release_revisions() release "topo_walk_info"
 - revisions API: have release_revisions() release "date_mode"
 - revisions API: call diff_free(&revs->pruning) in revisions_release()
 - revisions API: release "reflog_info" in release revisions()
 - revisions API: clear "boundary_commits" in release_revisions()
 - revisions API: have release_revisions() release "prune_data"
 - revisions API: have release_revisions() release "grep_filter"
 - revisions API: have release_revisions() release "filter"
 - revisions API: have release_revisions() release "cmdline"
 - revisions API: have release_revisions() release "mailmap"
 - revisions API: have release_revisions() release "commits"
 - revisions API users: use release_revisions() for "prune_data" users
 - revisions API users: use release_revisions() with UNLEAK()
 - revisions API users: use release_revisions() in builtin/log.c
 - revisions API users: use release_revisions() in http-push.c
 - revisions API users: add "goto cleanup" for release_revisions()
 - stash: always have the owner of "stash_info" free it
 - revisions API users: use release_revisions() needing REV_INFO_INIT
 - revision.[ch]: document and move code declared around "init"
 - revisions API users: add straightforward release_revisions()
 - revision.[ch]: provide and start using a release_revisions()
 - cocci: add and apply free_commit_list() rules
 - format-patch: don't leak "extra_headers" or "ref_message_ids"
 - string_list API users: use string_list_init_{no,}dup
 - blame: use "goto cleanup" for cleanup_scoreboard()
 - t/helper/test-fast-rebase.c: don't leak "struct strbuf"
 - Merge branch 'ds/partial-bundle-more' into ab/plug-leak-in-revisions

 Plug the memory leaks from the trickiest API of all, the revision
 walker.

 Will merge to 'next'?
 source: <cover-v5-00.27-00000000000-20220402T102002Z-avarab@gmail.com>


* ab/ci-github-workflow-markup (2022-03-27) 7 commits
 - ci: call `finalize_test_case_output` a little later
 - ci: use `--github-workflow-markup` in the GitHub workflow
 - ci: optionally mark up output in the GitHub workflow
 - test(junit): avoid line feeds in XML attributes
 - tests: refactor --write-junit-xml code
 - ci: make it easier to find failed tests' logs in the GitHub workflow
 - Merge branch 'ab/ci-setup-simplify' into ab/ci-github-workflow-markup
 (this branch uses ab/ci-setup-simplify.)

 Build a moral equivalent of js/ci-github-workflow-markup on top of
 ab/ci-setup-simplify.

 How does this compare feature-wise with js/ci-github-workflow-markup?
 source: <RFC-cover-v3-0.6-00000000000-20220325T183946Z-avarab@gmail.com>


* ab/ci-setup-simplify (2022-03-27) 25 commits
 - CI: don't use "set -x" in "ci/lib.sh" output
 - CI: set PYTHON_PATH setting for osx-{clang,gcc} into "$jobname" case
 - CI: set CC in MAKEFLAGS directly, don't add it to the environment
 - CI: add more variables to MAKEFLAGS, except under vs-build
 - CI: narrow down variable definitions in --build and --test
 - CI: only invoke ci/lib.sh as "steps" in main.yml
 - CI: pre-select test slice in Windows & VS tests
 - ci/run-test-slice.sh: replace shelling out with "echo"
 - CI: move "env" definitions into ci/lib.sh
 - CI: combine ci/install{,-docker}-dependencies.sh
 - CI: split up and reduce "ci/test-documentation.sh"
 - CI: invoke "make artifacts-tar" directly in windows-build
 - CI: check ignored unignored build artifacts in "win[+VS] build" too
 - CI: remove "run-build-and-tests.sh", run "make [test]" directly
 - CI: export variables via a wrapper
 - CI: consistently use "export" in ci/lib.sh
 - CI: move p4 and git-lfs variables to ci/install-dependencies.sh
 - CI: have "static-analysis" run "check-builtins", not "documentation"
 - CI: have "static-analysis" run a "make ci-static-analysis" target
 - CI: don't have "git grep" invoke a pager in tree content check
 - CI: remove unused Azure ci/* code
 - CI: remove dead "tree skipping" code
 - CI: remove more dead Travis CI support
 - CI: make "$jobname" explicit, remove fallback
 - CI: run "set -ex" early in ci/lib.sh
 (this branch is used by ab/ci-github-workflow-markup.)

 Drive more actions done in CI via the Makefile instead of shell
 commands sprinkled in .github/workflows/main.yml

 Unless "doing more in Makefile" is fundamentally undesirable, I am
 inclined to take this, together with ab/ci-github-workflow-markup
 to replace js/ci-github-workflow-markup
 cf. <xmqq4k361a57.fsf@gitster.g>
 source: <cover-v2-00.25-00000000000-20220325T182534Z-avarab@gmail.com>


* kf/p4-multiple-remotes (2022-03-21) 1 commit
 - git-p4: fix issue with multiple perforce remotes

 "git p4" update.

 Will merge to 'next'?
 source: <pull.1180.git.1647866603032.gitgitgadget@gmail.com>


* fr/vimdiff-layout (2022-04-03) 4 commits
  (merged to 'next' on 2022-04-04 at 5d1c8197d0)
 + mergetools: add description to all diff/merge tools
 + vimdiff: add tool documentation
 + vimdiff: integrate layout tests in the unit tests framework ('t' folder)
 + vimdiff: new implementation with layout support

 Reimplement "vimdiff[123]" mergetool drivers with a more generic
 layout mechanism.

 Will cook in 'next'.
 source: <20220330191909.294610-1-greenfoo@u92.eu>


* bc/stash-export (2022-04-08) 4 commits
 - builtin/stash: provide a way to import stashes from a ref
 - builtin/stash: provide a way to export stashes to a ref
 - builtin/stash: factor out revision parsing into a function
 - object-name: make get_oid quietly return an error

 A mechanism to export and import stash entries to and from a normal
 commit to transfer it across repositories has been introduced.

 Will merge to 'next'?
 source: <20220407215352.3491567-1-sandals@crustytoothpaste.net>


* ns/batch-fsync (2022-04-06) 13 commits
 - core.fsyncmethod: performance tests for batch mode
 - t/perf: add iteration setup mechanism to perf-lib
 - core.fsyncmethod: tests for batch mode
 - test-lib-functions: add parsing helpers for ls-files and ls-tree
 - core.fsync: use batch mode and sync loose objects by default on Windows
 - unpack-objects: use the bulk-checkin infrastructure
 - update-index: use the bulk-checkin infrastructure
 - builtin/add: add ODB transaction around add_files_to_cache
 - cache-tree: use ODB transaction around writing a tree
 - core.fsyncmethod: batched disk flushes for loose-objects
 - bulk-checkin: rebrand plug/unplug APIs as 'odb transactions'
 - bulk-checkin: rename 'state' variable and separate 'plugged' boolean
 - Merge branch 'ns/core-fsyncmethod' into ns/batch-fsync

 Introduce a filesystem-dependent mechanism to optimize the way the
 bits for many loose object files are ensured to hit the disk
 platter.

 Will merge to 'next'?
 source: <pull.1134.v5.git.1648616734.gitgitgadget@gmail.com>


* en/sparse-cone-becomes-default (2022-03-13) 9 commits
 - Documentation: some sparsity wording clarifications
 - git-sparse-checkout.txt: mark non-cone mode as deprecated
 - git-sparse-checkout.txt: flesh out non-cone mode pattern discussion a bit
 - git-sparse-checkout.txt: add a new EXAMPLES section
 - git-sparse-checkout.txt: shuffle some sections and mark as internal
 - git-sparse-checkout.txt: update docs for deprecation of 'init'
 - git-sparse-checkout.txt: wording updates for the cone mode default
 - sparse-checkout: make --cone the default
 - tests: stop assuming --no-cone is the default mode for sparse-checkout

 Deprecate non-cone mode of the sparse-checkout feature.

 Will merge to 'next'?
 source: <pull.1148.v2.git.1647054681.gitgitgadget@gmail.com>


* tb/cruft-packs (2022-03-02) 17 commits
 - sha1-file.c: don't freshen cruft packs
 - builtin/gc.c: conditionally avoid pruning objects via loose
 - builtin/repack.c: add cruft packs to MIDX during geometric repack
 - builtin/repack.c: use named flags for existing_packs
 - builtin/repack.c: allow configuring cruft pack generation
 - builtin/repack.c: support generating a cruft pack
 - builtin/pack-objects.c: --cruft with expiration
 - reachable: report precise timestamps from objects in cruft packs
 - reachable: add options to add_unseen_recent_objects_to_traversal
 - builtin/pack-objects.c: --cruft without expiration
 - builtin/pack-objects.c: return from create_object_entry()
 - t/helper: add 'pack-mtimes' test-tool
 - pack-mtimes: support writing pack .mtimes files
 - chunk-format.h: extract oid_version()
 - pack-write: pass 'struct packing_data' to 'stage_tmp_packfiles'
 - pack-mtimes: support reading .mtimes files
 - Documentation/technical: add cruft-packs.txt

 A mechanism to pack unreachable objects into a "cruft pack",
 instead of ejecting them into loose form to be reclaimed later, has
 been introduced.

 Waiting for discussion to settle.
 cf. <YiZI99yeijQe5Jaq@google.com>
 source: <cover.1646266835.git.me@ttaylorr.com>


* js/ci-github-workflow-markup (2022-03-01) 9 commits
 . ci: call `finalize_test_case_output` a little later
 . ci: use `--github-workflow-markup` in the GitHub workflow
 . ci: optionally mark up output in the GitHub workflow
 . test(junit): avoid line feeds in XML attributes
 . tests: refactor --write-junit-xml code
 . ci/run-build-and-tests: add some structure to the GitHub workflow output
 . ci: make it easier to find failed tests' logs in the GitHub workflow
 . ci/run-build-and-tests: take a more high-level view
 . ci: fix code style

 Update the GitHub workflow support to make it quicker to get to the
 failing test.

 Waiting for discussion to settle.
 cf. <220309.86tuc6lwpj.gmgdl@evledraar.gmail.com>
 cf. <220302.86mti87cj2.gmgdl@evledraar.gmail.com>
 cf. <30dbc8fb-a1db-05bc-3dcb-070e11cf4715@gmail.com>
 source: <pull.1117.v2.git.1646130289.gitgitgadget@gmail.com>


* et/xdiff-indirection (2022-02-17) 1 commit
 - xdiff: provide indirection to git functions

 Insert a layer of preprocessor macros for common functions in xdiff
 codebase.

 Expecting a reroll.
 cf. <xmqqbkyudb8n.fsf@gitster.g>
 source: <20220217225408.GB7@edef91d97c94>


* ab/http-gcc-12-workaround (2022-03-25) 1 commit
 - http API: fix dangling pointer issue noted by GCC 12.0

 Work around false warning pre-release of GCC 12.
 source: <patch-v3-1.1-69190804c67-20220325T143322Z-avarab@gmail.com>


* tk/simple-autosetupmerge (2022-02-25) 2 commits
 - t3200: tests for new branch.autosetupmerge option "simple"
 - merge: new autosetupmerge option 'simple' for matching branches

 "git -c branch.autosetupmerge=simple branch $A $B" will set the $B
 as $A's upstream only when $A and $B shares the same name, and "git
 -c push.default=simple" on branch $A would push to update the
 branch $A at the remote $B came from.

 Needs review.
 source: <pull.1161.v2.git.1645815142.gitgitgadget@gmail.com>


* tk/untracked-cache-with-uall (2022-04-01) 2 commits
  (merged to 'next' on 2022-04-04 at 2e11f1ac0c)
 + untracked-cache: support '--untracked-files=all' if configured
 + untracked-cache: test untracked-cache-bypassing behavior with -uall

 The performance of the "untracked cache" feature has been improved
 when "--untracked-files=<mode>" and "status.showUntrackedFiles"
 are combined.

 Will cook in 'next'.
 source: <pull.985.v6.git.1648742535.gitgitgadget@gmail.com>


* jh/builtin-fsmonitor-part3 (2022-03-25) 28 commits
 - t7527: test Unicode NFC/NFD handling on MacOS
 - t/lib-unicode-nfc-nfd: helper prereqs for testing unicode nfc/nfd
 - fsmonitor: on macOS also emit NFC spelling for NFD pathname
 - t7527: test FSMonitor on case insensitive+preserving file system
 - fsmonitor: never set CE_FSMONITOR_VALID on submodules
 - t/perf/p7527: add perf test for builtin FSMonitor
 - t7527: FSMonitor tests for directory moves
 - fsmonitor: optimize processing of directory events
 - fsm-listen-darwin: shutdown daemon if worktree root is moved/renamed
 - fsm-health-win32: force shutdown daemon if worktree root moves
 - fsm-health-win32: add polling framework to monitor daemon health
 - fsmonitor--daemon: stub in health thread
 - fsmonitor--daemon: rename listener thread related variables
 - fsmonitor--daemon: prepare for adding health thread
 - fsmonitor--daemon: cd out of worktree root
 - fsm-listen-darwin: ignore FSEvents caused by xattr changes on macOS
 - unpack-trees: initialize fsmonitor_has_run_once in o->result
 - fsmonitor-settings: NTFS and FAT32 on MacOS are incompatible
 - fsmonitor-settings: remote repos on Windows are incompatible
 - fsmonitor-settings: remote repos on macOS are incompatible
 - fsmonitor-settings: stub in macOS-specific incompatibility checking
 - fsmonitor-settings: VFS for Git virtual repos are incompatible
 - fsmonitor-settings: stub in Win32-specific incompatibility checking
 - fsmonitor-settings: bare repos are incompatible with FSMonitor
 - t/helper/fsmonitor-client: create stress test
 - t7527: test FSMonitor on repos with Unicode root paths
 - fsm-listen-win32: handle shortnames
 - Merge branch 'jh/builtin-fsmonitor-part2' into jh/builtin-fsmonitor-part3

 More fsmonitor--daemon.
 source: <pull.1143.v4.git.1648140680.gitgitgadget@gmail.com>


* js/bisect-in-c (2022-02-23) 14 commits
 - bisect: no longer try to clean up left-over `.git/head-name` files
 - bisect: remove Cogito-related code
 - bisect: turn `git bisect` into a full built-in
 - bisect: move even the option parsing to `bisect--helper`
 - bisect--helper: return only correct exit codes in `cmd_*()`
 - bisect--helper: move the `BISECT_STATE` case to the end
 - bisect--helper: make `--bisect-state` optional
 - bisect--helper: align the sub-command order with git-bisect.sh
 - bisect--helper: using `--bisect-state` without an argument is a bug
 - bisect--helper: really retire `--bisect-autostart`
 - bisect--helper: really retire --bisect-next-check
 - bisect--helper: retire the --no-log option
 - bisect: avoid double-quoting when printing the failed command
 - bisect run: fix the error message

 Final bits of "git bisect.sh" have been rewritten in C.

 Expecting a reroll.
 cf. <220225.86ilt27uln.gmgdl@evledraar.gmail.com>
 source: <pull.1132.v2.git.1645547423.gitgitgadget@gmail.com>


* js/scalar-diagnose (2022-02-06) 6 commits
 - scalar: teach `diagnose` to gather loose objects information
 - scalar: teach `diagnose` to gather packfile info
 - scalar diagnose: include disk space information
 - scalar: add `diagnose`
 - scalar: validate the optional enlistment argument
 - archive: optionally add "virtual" files

 Implementation of "scalar diagnose" subcommand.

 On hold.
 cf. <nycvar.QRO.7.76.6.2203012353090.11118@tvgsbejvaqbjf.bet>
 source: <pull.1128.v2.git.1644187146.gitgitgadget@gmail.com>


* en/merge-tree (2022-02-23) 13 commits
 - git-merge-tree.txt: add a section on potentional usage mistakes
 - merge-tree: add a --allow-unrelated-histories flag
 - merge-tree: allow `ls-files -u` style info to be NUL terminated
 - merge-tree: provide easy access to `ls-files -u` style info
 - merge-tree: provide a list of which files have conflicts
 - merge-ort: provide a merge_get_conflicted_files() helper function
 - merge-tree: support including merge messages in output
 - merge-ort: split out a separate display_update_messages() function
 - merge-tree: implement real merges
 - merge-tree: add option parsing and initial shell for real merge function
 - merge-tree: move logic for existing merge into new function
 - merge-tree: rename merge_trees() to trivial_merge_trees()
 - Merge branch 'en/remerge-diff' into en/merge-trees

 A new command is introduced that takes two commits and computes a
 tree that would be contained in the resulting merge commit, if the
 histories leading to these two commits were to be merged, and is
 added as a new mode of "git merge-tree" subcommand.

 On hold.
 cf. <CABPp-BGZ7OAYRR5YKRsxJSo-C=ho+qcNAkqwkim8CkhCfCeHsA@mail.gmail.com>
 source: <pull.1122.v6.git.1645602413.gitgitgadget@gmail.com>


* jh/p4-various-fixups (2022-04-01) 22 commits
  (merged to 'next' on 2022-04-04 at 251b14976f)
 + git-p4: sort imports
 + git-p4: seperate multiple statements onto seperate lines
 + git-p4: move inline comments to line above
 + git-p4: only seperate code blocks by a single empty line
 + git-p4: compare to singletons with "is" and "is not"
 + git-p4: normalize indentation of lines in conditionals
 + git-p4: ensure there is a single space around all operators
 + git-p4: ensure every comment has a single #
 + git-p4: remove spaces between dictionary keys and colons
 + git-p4: remove redundant backslash-continuations inside brackets
 + git-p4: remove extraneous spaces before function arguments
 + git-p4: place a single space after every comma
 + git-p4: removed brackets when assigning multiple return values
 + git-p4: remove spaces around default arguments
 + git-p4: remove padding from lists, tuples and function arguments
 + git-p4: sort and de-duplcate pylint disable list
 + git-p4: remove commented code
 + git-p4: convert descriptive class and function comments into docstrings
 + git-p4: improve consistency of docstring formatting
 + git-p4: indent with 4-spaces
 + git-p4: remove unneeded semicolons from statements
 + git-p4: add blank lines between functions and class definitions

 Various cleanups to "git p4".

 Will cook in 'next'.
 source: <20220401142504.58995-1-jholdsworth@nvidia.com>


* js/use-builtin-add-i (2021-12-01) 2 commits
 - add -i: default to the built-in implementation
 - t2016: require the PERL prereq only when necessary

 "git add -i" was rewritten in C some time ago and has been in
 testing; the reimplementation is now exposed to general public by
 default.

 On hold.

 What's the status of the "known breakage"?
 Are we ready to switch if we wanted to?
 There are known breakages on macOS.
 cf. <nycvar.QRO.7.76.6.2112021832060.63@tvgsbejvaqbjf.bet>
 source: <pull.1087.git.1638281655.gitgitgadget@gmail.com>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: What's cooking in git.git (Apr 2022, #03; Tue, 12)
  2022-04-12 17:04 What's cooking in git.git (Apr 2022, #03; Tue, 12) Junio C Hamano
@ 2022-04-12 17:52 ` Philippe Blain
  2022-04-12 18:55   ` CVE-2022-24765 and core.sharedRepository (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason
  2022-04-13 23:51   ` What's cooking in git.git (Apr 2022, #03; Tue, 12) Junio C Hamano
  2022-04-13 20:08 ` ab/plug-leak-in-revisions (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason
  2022-04-13 20:11 ` ab/ci-setup-simplify etc. (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason
  2 siblings, 2 replies; 10+ messages in thread
From: Philippe Blain @ 2022-04-12 17:52 UTC (permalink / raw)
  To: Junio C Hamano, git, Johannes Schindelin

Hi Junio,

Le 2022-04-12 à 13:04, Junio C Hamano a écrit :
> 
> 
> Security releases for the 2.30-2.35 maintenance tracks have been
> tagged to address CVE-2022-24765, which allows a user to trick other
> users into running a command of their choice easily on multi-user
> machines with a shared "mob" directory.  The fix has been also
> merged to Git 2.36-rc2 and to all integration branches.
> 

This is quite a big behaviour change for some environments [1], so I would think maybe it
deserves to be fully spelled out in the release notes for 2.36.0,
instead of just referring readers to the release notes for the maintenance
release, where they can read a full description only in the release notes
for 2.30.3 ?

Thanks,
Philippe.

[1] the commit message for the change mentions "shared directories", 
but in some environments, it is quite common for each user to have
read access to other uers's home directories. I'm mostly thinking about
high performance computing clusters, which is the kind of systems I have 
experience with. This makes it really easy for local
"git experts" to 'cd' into a colleague's repo and help them when they 
are facing a Git problem. The fact that it won't be possible to do that
without manually invoking 'git config --add safe.directory $PWD' beforehand
is a little sad... What were the arguments for specifically disabling
'git -c safe.directory' for this fix ?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* CVE-2022-24765 and core.sharedRepository (was: What's cooking in git.git (Apr 2022, #03; Tue, 12))
  2022-04-12 17:52 ` Philippe Blain
@ 2022-04-12 18:55   ` Ævar Arnfjörð Bjarmason
  2022-04-13  3:10     ` demerphq
  2022-04-13 23:51   ` What's cooking in git.git (Apr 2022, #03; Tue, 12) Junio C Hamano
  1 sibling, 1 reply; 10+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-04-12 18:55 UTC (permalink / raw)
  To: Philippe Blain; +Cc: Junio C Hamano, git, Johannes Schindelin


On Tue, Apr 12 2022, Philippe Blain wrote:

[A change of $subject seems in order]

> Le 2022-04-12 à 13:04, Junio C Hamano a écrit :
>> 
>> 
>> Security releases for the 2.30-2.35 maintenance tracks have been
>> tagged to address CVE-2022-24765, which allows a user to trick other
>> users into running a command of their choice easily on multi-user
>> machines with a shared "mob" directory.  The fix has been also
>> merged to Git 2.36-rc2 and to all integration branches.
>> 
>
> This is quite a big behaviour change for some environments [1], so I would think maybe it
> deserves to be fully spelled out in the release notes for 2.36.0,
> instead of just referring readers to the release notes for the maintenance
> release, where they can read a full description only in the release notes
> for 2.30.3 ?

Yes, I think it deserves to be noted very prominently, and also that we
had some mechanism for publishing relevant git-security@ discussions
(possibly with some parts redacted) after the issues become public.

Non knowing if others involved are OK with being quoted I'll just say
that this issue was discussed at some length on the list, in particular
that it'll severely hinder some core.sharedRepository workflows.

Quoting (part of) my own reply from one of those exchanges (this is in
reply to Johannes Schindelin):

	But I don't understand why we need to immediately die() when we detect
	this situation in setup.c.
	
	Why don't we just detect it, then set a:
	
	        naughty_fsmonitor = "/scratch/.git"
	
	And then later:
	
	        diff --git a/config.c b/config.c
	        index 383b1a4885b..c9ac12e47b0 100644
	        --- a/config.c
	        +++ b/config.c
	        @@ -2630,6 +2630,9 @@ int git_config_get_fsmonitor(void)
	         {
	                if (git_config_get_pathname("core.fsmonitor", &core_fsmonitor))
	                        core_fsmonitor = getenv("GIT_TEST_FSMONITOR");
	        +       else if (naughty_fsmonitor)
	        +               die(_("zOMG we got a core.fsmonitor setting from a possibly bad path '%s' ..."),
	        +                   git_config_get_fsmonitor);
	
	                if (core_fsmonitor && !*core_fsmonitor)
	                        core_fsmonitor = NULL;
	
	Where the "..." would be some version of your advice in 2/2 about
	safe.directory, which would also cause "naughty_fsmonitor" to remain
	NULL in this case.
	
	Doesn't that give us all of the relevant security mitigation without
	potentially breaking users in the wild who are relying on git to work in
	the core.sharedRepository case?
	
	To Edward's upthread "I will wager a handsome sum[...]" comment: An
	ex-employer has exactly that setup, with AFAIK on the orders of thousand
	of users (a shared directory deployment system across a fleet of
	"staging" servers).
	
	I'd really like us to avoid unduly disrupting those kinds of setups if
	we can help it.
	
	In this case doing so seems like a rather easy addition: Let's ignore
	and/or die on the combination of this sort of "unsafe" directory and
	core.fsmonitor in particular. No?

That patch doesn't apply anymore (recent fsmonitor changes), but I still
think something like that would be a nice thing to have, e.g. being able
to configure in /etc/gitconfig that "this system is OK with not needing
safe.directory whitelisting, except maybe for core.fsmonitor".

Hopefully Johannes will chime in, but I think it's fair to say that
(this is just a summarizing from memory, I've surely missed some bits):

 * Yes, for the *known* issues we could go for a much more narrow
   solution (something like the above).

 * There are other bits of config that also point to executable things,
   e.g. core.editor, aliases etc, but nothing has been found yet that
   provides the "at a distance" effect that the core.fsmonitor vector
   does.

   I.e. a user is unlikely to go to /tmp/some-crap/here and run "git
   commit", but they (or their shell prompt) might run "git status", and
   if you have a /tmp/.git ...

 * Third-party software is also a wildcard here, i.e. we can know that
   for git itself we have such-and-such interaction with core.editor or
   whatever, but is the same true of the plethora of third-party git
   integrations?

 * Johannes et al were concerned that with the cat being out of the bag
   (as it were) other similar issues would be poked at/discovered.

 * Therefore a more thorough initial solution was preferred.

And maybe?:

 * Now that this is out, the people involved would be OK with discussing
   something more surgical, in particular to accommodate the
   core.sharedRepository case (after the current rc phase, preferably).

In any case, the core.sharedRepository case isn't personally my itch to
scratch anymore, so I'm not going to pursue this, but perhaps someone
else is interested...

> [1] the commit message for the change mentions "shared directories", 
> but in some environments, it is quite common for each user to have
> read access to other uers's home directories. I'm mostly thinking about
> high performance computing clusters, which is the kind of systems I have 
> experience with. This makes it really easy for local
> "git experts" to 'cd' into a colleague's repo and help them when they 
> are facing a Git problem. The fact that it won't be possible to do that
> without manually invoking 'git config --add safe.directory $PWD' beforehand
> is a little sad... What were the arguments for specifically disabling
> 'git -c safe.directory' for this fix ?

I wasn't aware/hadn't noticed that aspect of it, but I don't think
that's "by design" or whatever, but just an "and by the way..." in
8959555cee7 (setup_git_directory(): add an owner check for the top-level
directory, 2022-03-02).

I.e. for no particularly good reason other than historical codebase
growth we'll parse the command-line in git.c after we run the setup.c
bits, which I believe is the reason this isn't supported on the
command-line.

The same is true for the trace2.* config, which likewise is for no
particular reason other than nobody felt like refactoring that tricky
core bit of code to make it work.

I.e. if you go back and read the discussions when the trace2.* config
was added it was essentially a "yeah, -c would be nice, but this is good
enough", and not "we'd like to forbid -c by design".

I hope all of that helps.

P.s.: For anyone wanting to hoist the "-c" handling earlier this is
probably a good start:
https://lore.kernel.org/git/220128.8635l7d7y6.gmgdl@evledraar.gmail.com/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: CVE-2022-24765 and core.sharedRepository (was: What's cooking in git.git (Apr 2022, #03; Tue, 12))
  2022-04-12 18:55   ` CVE-2022-24765 and core.sharedRepository (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason
@ 2022-04-13  3:10     ` demerphq
  0 siblings, 0 replies; 10+ messages in thread
From: demerphq @ 2022-04-13  3:10 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Philippe Blain, Junio C Hamano, Git, Johannes Schindelin

On Tue, 12 Apr 2022 at 21:43, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> On Tue, Apr 12 2022, Philippe Blain wrote:
>
> [A change of $subject seems in order]
>
> > Le 2022-04-12 à 13:04, Junio C Hamano a écrit :
> >>
> >>
> >> Security releases for the 2.30-2.35 maintenance tracks have been
> >> tagged to address CVE-2022-24765, which allows a user to trick other
> >> users into running a command of their choice easily on multi-user
> >> machines with a shared "mob" directory.  The fix has been also
> >> merged to Git 2.36-rc2 and to all integration branches.
> >>
> >
> > This is quite a big behaviour change for some environments [1], so I would think maybe it
> > deserves to be fully spelled out in the release notes for 2.36.0,
> > instead of just referring readers to the release notes for the maintenance
> > release, where they can read a full description only in the release notes
> > for 2.30.3 ?
>
> Yes, I think it deserves to be noted very prominently, and also that we
> had some mechanism for publishing relevant git-security@ discussions
> (possibly with some parts redacted) after the issues become public.
>
> Non knowing if others involved are OK with being quoted I'll just say
> that this issue was discussed at some length on the list, in particular
> that it'll severely hinder some core.sharedRepository workflows.
>
> Quoting (part of) my own reply from one of those exchanges (this is in
> reply to Johannes Schindelin):
>
>         But I don't understand why we need to immediately die() when we detect
>         this situation in setup.c.

Would I be right in thinking this explains new breakage we are seeing
in CI jobs we (the Perl project) have hosted on GitHub:

https://github.com/Perl/perl5/runs/6000831257?check_suite_focus=true#step:5:1

Run git remote set-url origin "***github.com/$GITHUB_REPOSITORY"
fatal: unsafe repository ('/__w/perl5/perl5' is owned by someone else)
To add an exception for this directory, call:

git config --global --add safe.directory /__w/perl5/perl5
Process completed with exit code 128.

Cheers,
Yves

^ permalink raw reply	[flat|nested] 10+ messages in thread

* ab/plug-leak-in-revisions (was: What's cooking in git.git (Apr 2022, #03; Tue, 12))
  2022-04-12 17:04 What's cooking in git.git (Apr 2022, #03; Tue, 12) Junio C Hamano
  2022-04-12 17:52 ` Philippe Blain
@ 2022-04-13 20:08 ` Ævar Arnfjörð Bjarmason
  2022-04-13 23:32   ` ab/plug-leak-in-revisions Junio C Hamano
  2022-04-13 20:11 ` ab/ci-setup-simplify etc. (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason
  2 siblings, 1 reply; 10+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-04-13 20:08 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Phillip Wood


On Tue, Apr 12 2022, Junio C Hamano wrote:

> * ab/plug-leak-in-revisions (2022-04-03) 28 commits
>  - revisions API: add a TODO for diff_free(&revs->diffopt)
>  - revisions API: have release_revisions() release "topo_walk_info"
>  - revisions API: have release_revisions() release "date_mode"
>  - revisions API: call diff_free(&revs->pruning) in revisions_release()
>  - revisions API: release "reflog_info" in release revisions()
>  - revisions API: clear "boundary_commits" in release_revisions()
>  - revisions API: have release_revisions() release "prune_data"
>  - revisions API: have release_revisions() release "grep_filter"
>  - revisions API: have release_revisions() release "filter"
>  - revisions API: have release_revisions() release "cmdline"
>  - revisions API: have release_revisions() release "mailmap"
>  - revisions API: have release_revisions() release "commits"
>  - revisions API users: use release_revisions() for "prune_data" users
>  - revisions API users: use release_revisions() with UNLEAK()
>  - revisions API users: use release_revisions() in builtin/log.c
>  - revisions API users: use release_revisions() in http-push.c
>  - revisions API users: add "goto cleanup" for release_revisions()
>  - stash: always have the owner of "stash_info" free it
>  - revisions API users: use release_revisions() needing REV_INFO_INIT
>  - revision.[ch]: document and move code declared around "init"
>  - revisions API users: add straightforward release_revisions()
>  - revision.[ch]: provide and start using a release_revisions()
>  - cocci: add and apply free_commit_list() rules
>  - format-patch: don't leak "extra_headers" or "ref_message_ids"
>  - string_list API users: use string_list_init_{no,}dup
>  - blame: use "goto cleanup" for cleanup_scoreboard()
>  - t/helper/test-fast-rebase.c: don't leak "struct strbuf"
>  - Merge branch 'ds/partial-bundle-more' into ab/plug-leak-in-revisions
>
>  Plug the memory leaks from the trickiest API of all, the revision
>  walker.
>
>  Will merge to 'next'?
>  source: <cover-v5-00.27-00000000000-20220402T102002Z-avarab@gmail.com>

I think it should be ready with my just-submitted re-roll, which fixes a
trivial nit spotted by Phillip Wood by removing a useless NULL check:
https://lore.kernel.org/git/cover-v6-00.27-00000000000-20220413T195935Z-avarab@gmail.com/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* ab/ci-setup-simplify etc. (was: What's cooking in git.git (Apr 2022, #03; Tue, 12))
  2022-04-12 17:04 What's cooking in git.git (Apr 2022, #03; Tue, 12) Junio C Hamano
  2022-04-12 17:52 ` Philippe Blain
  2022-04-13 20:08 ` ab/plug-leak-in-revisions (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason
@ 2022-04-13 20:11 ` Ævar Arnfjörð Bjarmason
  2 siblings, 0 replies; 10+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-04-13 20:11 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Victoria Dye, Johannes Schindelin


On Tue, Apr 12 2022, Junio C Hamano wrote:

> * ab/ci-github-workflow-markup (2022-03-27) 7 commits
>  - ci: call `finalize_test_case_output` a little later
>  - ci: use `--github-workflow-markup` in the GitHub workflow
>  - ci: optionally mark up output in the GitHub workflow
>  - test(junit): avoid line feeds in XML attributes
>  - tests: refactor --write-junit-xml code
>  - ci: make it easier to find failed tests' logs in the GitHub workflow
>  - Merge branch 'ab/ci-setup-simplify' into ab/ci-github-workflow-markup
>  (this branch uses ab/ci-setup-simplify.)
>
>  Build a moral equivalent of js/ci-github-workflow-markup on top of
>  ab/ci-setup-simplify.
>
>  How does this compare feature-wise with js/ci-github-workflow-markup?
>  source: <RFC-cover-v3-0.6-00000000000-20220325T183946Z-avarab@gmail.com>

...[covered below]...

> * ab/ci-setup-simplify (2022-03-27) 25 commits
>  - CI: don't use "set -x" in "ci/lib.sh" output
>  - CI: set PYTHON_PATH setting for osx-{clang,gcc} into "$jobname" case
>  - CI: set CC in MAKEFLAGS directly, don't add it to the environment
>  - CI: add more variables to MAKEFLAGS, except under vs-build
>  - CI: narrow down variable definitions in --build and --test
>  - CI: only invoke ci/lib.sh as "steps" in main.yml
>  - CI: pre-select test slice in Windows & VS tests
>  - ci/run-test-slice.sh: replace shelling out with "echo"
>  - CI: move "env" definitions into ci/lib.sh
>  - CI: combine ci/install{,-docker}-dependencies.sh
>  - CI: split up and reduce "ci/test-documentation.sh"
>  - CI: invoke "make artifacts-tar" directly in windows-build
>  - CI: check ignored unignored build artifacts in "win[+VS] build" too
>  - CI: remove "run-build-and-tests.sh", run "make [test]" directly
>  - CI: export variables via a wrapper
>  - CI: consistently use "export" in ci/lib.sh
>  - CI: move p4 and git-lfs variables to ci/install-dependencies.sh
>  - CI: have "static-analysis" run "check-builtins", not "documentation"
>  - CI: have "static-analysis" run a "make ci-static-analysis" target
>  - CI: don't have "git grep" invoke a pager in tree content check
>  - CI: remove unused Azure ci/* code
>  - CI: remove dead "tree skipping" code
>  - CI: remove more dead Travis CI support
>  - CI: make "$jobname" explicit, remove fallback
>  - CI: run "set -ex" early in ci/lib.sh
>  (this branch is used by ab/ci-github-workflow-markup.)
>
>  Drive more actions done in CI via the Makefile instead of shell
>  commands sprinkled in .github/workflows/main.yml
>
>  Unless "doing more in Makefile" is fundamentally undesirable, I am
>  inclined to take this, together with ab/ci-github-workflow-markup
>  to replace js/ci-github-workflow-markup
>  cf. <xmqq4k361a57.fsf@gitster.g>
>  source: <cover-v2-00.25-00000000000-20220325T182534Z-avarab@gmail.com>

With the RC period hopefully the timing of the re-rolls I submitted is
more helpful than not (since you were considering things for "next").

I think this should be ready, the main critique of this series on its
merits I think has been[1], I was a bit on the fence about adding
something on top of it, but hopefully the re-roll at [2] helps address
that, i.e. by explicitly adding the support for running things "CI-like"
locally, which was the logical conclusion of this series (in addition to
improving the GitHub CI UX itself).

> * js/ci-github-workflow-markup (2022-03-01) 9 commits
>  . ci: call `finalize_test_case_output` a little later
>  . ci: use `--github-workflow-markup` in the GitHub workflow
>  . ci: optionally mark up output in the GitHub workflow
>  . test(junit): avoid line feeds in XML attributes
>  . tests: refactor --write-junit-xml code
>  . ci/run-build-and-tests: add some structure to the GitHub workflow output
>  . ci: make it easier to find failed tests' logs in the GitHub workflow
>  . ci/run-build-and-tests: take a more high-level view
>  . ci: fix code style
>
>  Update the GitHub workflow support to make it quicker to get to the
>  failing test.
>
>  Waiting for discussion to settle.
>  cf. <220309.86tuc6lwpj.gmgdl@evledraar.gmail.com>
>  cf. <220302.86mti87cj2.gmgdl@evledraar.gmail.com>
>  cf. <30dbc8fb-a1db-05bc-3dcb-070e11cf4715@gmail.com>
>  source: <pull.1117.v2.git.1646130289.gitgitgadget@gmail.com>

Feature-wise v.s. ab/ci-github-workflow-markup one thing I noticed after
submitting the initial re-roll is that my re-roll has the end of the
"prove" output immediately preceding the expandable toggles in
js/ci-github-workflow-markup, but in js/ci-github-workflow-markup the
"prove" output is hidden its its own "toggle".

It's an artifact of how the two combined, the
js/ci-github-workflow-markup way could be re-introduced, but I find the
combination quite helpful actually. I.e. we now see the general summary
of what tests failed, and then the set test-by-test failures below.

As for the overall status some of the UX/slowness issues remain
unaddressed, which are issues in the original
js/ci-github-workflow-markup carried forward in this one.

Victoria Dye had some suggestions for addressing the slowness in [3]
that I think should be followed-up on. It was also noted that part of
the output was duplicated in the series (didn't dig up that reference,
sorry).

1. https://lore.kernel.org/git/320b3dde-a84e-0074-bed8-57061293b2b0@github.com/
2. https://lore.kernel.org/git/cover-v3-00.29-00000000000-20220413T194847Z-avarab@gmail.com/
3. https://lore.kernel.org/git/6b83bb83-32b9-20c9-fa02-c1c3170351c3@github.com/


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ab/plug-leak-in-revisions
  2022-04-13 20:08 ` ab/plug-leak-in-revisions (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason
@ 2022-04-13 23:32   ` Junio C Hamano
  2022-04-14  7:22     ` ab/plug-leak-in-revisions Ævar Arnfjörð Bjarmason
  0 siblings, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2022-04-13 23:32 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason; +Cc: git, Phillip Wood

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> I think it should be ready with my just-submitted re-roll, which fixes a
> trivial nit spotted by Phillip Wood by removing a useless NULL check:
> https://lore.kernel.org/git/cover-v6-00.27-00000000000-20220413T195935Z-avarab@gmail.com/

Last time I checked, the last three patches haven't made to the lore
archive yet.  We have other things to do while waiting for them, so
there is no need to rush or resend ;-)


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: What's cooking in git.git (Apr 2022, #03; Tue, 12)
  2022-04-12 17:52 ` Philippe Blain
  2022-04-12 18:55   ` CVE-2022-24765 and core.sharedRepository (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason
@ 2022-04-13 23:51   ` Junio C Hamano
  1 sibling, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2022-04-13 23:51 UTC (permalink / raw)
  To: Philippe Blain; +Cc: git, Johannes Schindelin

Philippe Blain <levraiphilippeblain@gmail.com> writes:

> This is quite a big behaviour change for some environments [1], so
> I would think maybe it deserves to be fully spelled out in the
> release notes for 2.36.0, instead of just referring readers to the
> release notes for the maintenance release, where they can read a
> full description only in the release notes for 2.30.3 ?

Makes sense.  Here is my quick-and-dirty first draft, based on the
design of the new escape hatch done by Derrick today.

diff --git c/Documentation/RelNotes/2.36.0.txt w/Documentation/RelNotes/2.36.0.txt
index 9f6dd3d868..f4c5e691bb 100644
--- c/Documentation/RelNotes/2.36.0.txt
+++ w/Documentation/RelNotes/2.36.0.txt
@@ -13,6 +13,15 @@ Backward compatibility warts
    top-level a partial clone, while submodules are fully cloned.  This
    behaviour is changed to pass the same filter down to the submodules.
 
+ * With the fixes for CVE-2022-24765 that are common with versions of
+   Git 2.30.4, 2.31.3, 2.32.2, 2.33.3, 2.34.3, and 2.35.3, Git has
+   been taught not to recognise repositories owned by other users, in
+   order to avoid getting affected by their config files and hooks.
+   You can list the path to the safe/trusted repositories that may be
+   owned by others on a multi-valued configuration variable
+   `safe.directory` to override this behaviour, or use '*' to declare
+   that you trust anything.
+
 
 Note to those who build from the source
 
@@ -397,8 +406,6 @@ Fixes since v2.35
    entry it moved.
    (merge b7f9130a06 vd/mv-refresh-stat later to maint).
 
- * Fix for CVE-2022-24765 has been merged up from 2.35.2 and others.
-
  * Other code cleanup, docfix, build fix, etc.
    (merge cfc5cf428b jc/find-header later to maint).
    (merge 40e7cfdd46 jh/p4-fix-use-of-process-error-exception later to maint).

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: ab/plug-leak-in-revisions
  2022-04-13 23:32   ` ab/plug-leak-in-revisions Junio C Hamano
@ 2022-04-14  7:22     ` Ævar Arnfjörð Bjarmason
  2022-04-14 18:33       ` ab/plug-leak-in-revisions Junio C Hamano
  0 siblings, 1 reply; 10+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-04-14  7:22 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Phillip Wood


On Wed, Apr 13 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> I think it should be ready with my just-submitted re-roll, which fixes a
>> trivial nit spotted by Phillip Wood by removing a useless NULL check:
>> https://lore.kernel.org/git/cover-v6-00.27-00000000000-20220413T195935Z-avarab@gmail.com/
>
> Last time I checked, the last three patches haven't made to the lore
> archive yet.  We have other things to do while waiting for them, so
> there is no need to rush or resend ;-)

git-send-email died at the end of that send, I picked up where I left
off and sent the remaining three.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ab/plug-leak-in-revisions
  2022-04-14  7:22     ` ab/plug-leak-in-revisions Ævar Arnfjörð Bjarmason
@ 2022-04-14 18:33       ` Junio C Hamano
  0 siblings, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2022-04-14 18:33 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason; +Cc: git, Phillip Wood

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Wed, Apr 13 2022, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>
>>> I think it should be ready with my just-submitted re-roll, which fixes a
>>> trivial nit spotted by Phillip Wood by removing a useless NULL check:
>>> https://lore.kernel.org/git/cover-v6-00.27-00000000000-20220413T195935Z-avarab@gmail.com/
>>
>> Last time I checked, the last three patches haven't made to the lore
>> archive yet.  We have other things to do while waiting for them, so
>> there is no need to rush or resend ;-)
>
> git-send-email died at the end of that send, I picked up where I left
> off and sent the remaining three.

Thanks.  All replaced and the change from the previous round was as
expected.

Looking great.



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-04-14 18:33 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-12 17:04 What's cooking in git.git (Apr 2022, #03; Tue, 12) Junio C Hamano
2022-04-12 17:52 ` Philippe Blain
2022-04-12 18:55   ` CVE-2022-24765 and core.sharedRepository (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason
2022-04-13  3:10     ` demerphq
2022-04-13 23:51   ` What's cooking in git.git (Apr 2022, #03; Tue, 12) Junio C Hamano
2022-04-13 20:08 ` ab/plug-leak-in-revisions (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason
2022-04-13 23:32   ` ab/plug-leak-in-revisions Junio C Hamano
2022-04-14  7:22     ` ab/plug-leak-in-revisions Ævar Arnfjörð Bjarmason
2022-04-14 18:33       ` ab/plug-leak-in-revisions Junio C Hamano
2022-04-13 20:11 ` ab/ci-setup-simplify etc. (was: What's cooking in git.git (Apr 2022, #03; Tue, 12)) Ævar Arnfjörð Bjarmason

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).