{"thread":{"id":"53555","subject":"What's cooking in git.git (May 2020, #09; Tue, 26)","startedAt":"2020-05-26T18:48:09Z","lastAt":"2020-05-28T14:44:53Z","messageCount":7,"participants":["Junio C Hamano","Johannes Schindelin","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"398594","messageId":"xmqqsgfmmt2c.fsf@gitster.c.googlers.com","threadId":"53555","inReplyTo":null,"subject":"What's cooking in git.git (May 2020, #09; Tue, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-26T18:47:55Z","receivedAt":"2020-05-26T18:48:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'.  The ones marked with '.' do not appear in any of\nthe integration branches, but I am still holding onto them.\n\nGit 2.27-rc2 has been tagged.\n\nYou can find the changes described here in the integration branches\nof the repositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* ss/faq-ignore (2020-05-25) 1 commit\n  (merged to 'next' on 2020-05-25 at f2f7dd2ff6)\n + gitfaq: avoid validation error with older asciidoc\n\n Doc markup fix.\n\n--------------------------------------------------\n[New Topics]\n\n* en/sparse-with-submodule-doc (2020-05-25) 1 commit\n - git-sparse-checkout: clarify interactions with submodules\n\n\n* ma/rev-list-options-docfix (2020-05-26) 1 commit\n - rev-list-options.txt: start a list for `show-pulls`\n\n--------------------------------------------------\n[Stalled]\n\n* dr/push-remoteref-fix (2020-04-23) 1 commit\n - remote.c: fix handling of %(push:remoteref)\n\n The \"%(push:remoteref)\" placeholder in the \"--format=\" argument of\n \"git format-patch\" (and friends) only showed what got explicitly\n configured, not what ref at the receiving end would be updated when\n \"git push\" was used, as it ignored the default behaviour (e.g. update\n the same ref as the source).\n\n Expecting a reroll.\n cf. <20200416152145.wp2zeibxmuyas6y6@feanor>\n\n\n* jk/complete-git-switch (2020-04-28) 11 commits\n - completion: complete remote branches for git switch --track\n - completion: recognize -c/-C when completing for git switch\n - completion: fix completion for git switch with no options\n - completion: perform DWIM logic directly in __git_complete_refs\n - completion: extract function __git_dwim_remote_heads\n - completion: rename --track option of __git_complete_refs\n - completion: stop completing refs for git switch --orphan\n - completion: add tests showing lack of support for git switch -c/-C\n - completion: add test highlighting subpar git switch --track completion\n - completion: add test showing subpar git switch completion\n - completion: add some simple test cases for git switch completion\n\n The command line completion (in contrib/) learned to complete\n options that the \"git switch\" command takes.\n\n Needs review.\n\n\n* dl/test-must-fail-fixes-5 (2020-05-21) 5 commits\n - lib-submodule-update: pass OVERWRITING_FAIL\n - SQUASH???  <20200521112545.GB581643@generichostname>\n - lib-submodule-update: prepend \"git\" to $command\n - lib-submodule-update: consolidate --recurse-submodules\n - lib-submodule-update: add space after function name\n\n The effort to avoid using test_must_fail on non-git command continues.\n\n Waiting for a review thread to settle.\n cf. <20200521182928.GA1308647@coredump.intra.peff.net>\n The last step is a bit too ugly to live; Peff seems to have better\n ideas.\n\n\n* mr/bisect-in-c-2 (2020-04-23) 12 commits\n - bisect--helper: retire `--bisect-autostart` subcommand\n - bisect--helper: retire `--write-terms` subcommand\n - bisect--helper: retire `--check-expected-revs` subcommand\n - bisect--helper: reimplement `bisect_state` & `bisect_head` shell functions in C\n - bisect--helper: retire `--next-all` subcommand\n - bisect--helper: retire `--bisect-clean-state` subcommand\n - bisect--helper: finish porting `bisect_start()` to C\n - bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C\n - bisect--helper: reimplement `bisect_autostart` shell function in C\n - bisect--helper: introduce new `write_in_file()` function\n - bisect--helper: use '-res' in 'cmd_bisect__helper' return\n - bisect--helper: fix `cmd_*()` function switch default return\n\n Rewrite of the remainder of \"git bisect\" script in C continues.\n\n Expecting a response to reviews.\n cf. <nycvar.QRO.7.76.6.2005230007260.56@tvgsbejvaqbjf.bet>\n\n\n* mk/use-size-t-in-zlib (2018-10-15) 1 commit\n - zlib.c: use size_t for size\n\n The wrapper to call into zlib followed our long tradition to use\n \"unsigned long\" for sizes of regions in memory, which have been\n updated to use \"size_t\".\n\n--------------------------------------------------\n[Cooking]\n\n* bc/filter-process (2020-05-21) 2 commits\n  (merged to 'next' on 2020-05-24 at 3d51328096)\n + t2060: add a test for switch with --orphan and --discard-changes\n + builtin/checkout: simplify metadata initialization\n\n Code simplification and test coverage enhancement.\n\n Will cook in 'next'.\n\n\n* cb/bisect-helper-parser-fix (2020-05-24) 1 commit\n  (merged to 'next' on 2020-05-24 at d30e10fa86)\n + bisect--helper: avoid segfault with bad syntax in `start --term-*`\n\n The code to parse \"git bisect start\" command line was lax in\n validating the arguments.\n\n Will cook in 'next'.\n\n\n* jn/experimental-opts-into-proto-v2 (2020-05-21) 1 commit\n  (merged to 'next' on 2020-05-24 at 53cd664dfe)\n + config: let feature.experimental imply protocol.version=2\n\n \"feature.experimental\" configuration variable is to let volunteers\n easily opt into a set of newer features, which use of the v2\n transport protocol is now a part of.\n\n Will cook in 'next'.\n\n\n* jx/pkt-line-doc-count-fix (2020-05-21) 1 commit\n  (merged to 'next' on 2020-05-24 at 7115240db4)\n + doc: fix wrong 4-byte length of pkt-line message\n\n Docfix.\n\n Will cook in 'next'.\n\n\n* rs/fsck-duplicate-names-in-trees (2020-05-21) 4 commits\n  (merged to 'next' on 2020-05-24 at 6e1d6ba087)\n + fsck: detect more in-tree d/f conflicts\n + t1450: demonstrate undetected in-tree d/f conflict\n + t1450: increase test coverage of in-tree d/f detection\n + fsck: fix a typo in a comment\n\n The check in \"git fsck\" to ensure that the tree objects are sorted\n still had corner cases it missed unsorted entries.\n\n Will cook in 'next'.\n\n\n* ss/submodule-set-branch-in-c (2020-05-24) 2 commits\n - fixup! submodule: port subcommand 'set-branch' from shell to C\n - submodule: port subcommand 'set-branch' from shell to C\n\n Rewrite of parts of the scripted \"git submodule\" Porcelain command\n continues; this time it is \"git submodule set-branch\" subcommand's\n turn.\n\n cf. <20200523231838.GB1981@danh.dev>\n\n\n* vs/complete-stash-show-p-fix (2020-05-21) 1 commit\n  (merged to 'next' on 2020-05-24 at fcbff29a0f)\n + completion: don't override given stash subcommand with -p\n\n The command line completion script (in contrib/) tried to complete\n \"git stash -p\" as if it were \"git stash push -p\", but it was too\n aggressive and also affected \"git stash show -p\", which has been\n corrected.\n\n Will cook in 'next'.\n\n\n* cb/t5608-cleanup (2020-05-24) 1 commit\n  (merged to 'next' on 2020-05-24 at 2bfa581890)\n + t5608: avoid say() and use \"skip_all\" instead for consistency\n\n Test fixup.\n\n Will cook in 'next'.\n\n\n* es/config-hooks (2020-05-21) 4 commits\n . hook: add --porcelain to list command\n . hook: add list command\n . hook: scaffolding for git-hook subcommand\n . doc: propose hooks managed by the config\n\n\n* rs/checkout-b-track-error (2020-05-24) 2 commits\n  (merged to 'next' on 2020-05-26 at 9220e43203)\n + checkout: improve error messages for -b with extra argument\n + checkout: add tests for -b and --track\n\n The error message from \"git checkout -b foo -t bar baz\" was\n confusing.\n\n Will cook in 'next'.\n\n\n* lo/sparse-universal-zero-init (2020-05-24) 1 commit\n  (merged to 'next' on 2020-05-24 at 1f4ea6b348)\n + sparse: allow '{ 0 }' to be used without warnings\n\n We've adopted a convention that any on-stack structure can be\n initialized to have zero values in all fields with \"= { 0 }\", even\n when the first field happens to be a pointer, but sparse complained\n that a null pointer should be spelled NULL for a long time.  Start\n using -Wno-universal-initializer option to squelch it.\n\n Will cook in 'next'.\n\n\n* pw/rebase-i-more-options (2020-05-24) 5 commits\n - rebase: add --reset-author-date\n - rebase -i: support --ignore-date\n - sequencer: rename amend_author to author_to_free\n - rebase -i: support --committer-date-is-author-date\n - rebase -i: add --ignore-whitespace flag\n\n \"git rebase -i\" learns a bit more options.\n\n Expecting the final touch\n cf. <20200523155203.GA10163@danh.dev>\n\n\n* an/merge-single-strategy-optim (2020-05-19) 1 commit\n  (merged to 'next' on 2020-05-20 at 8d5cacc8d1)\n + merge: optimization to skip evaluate_result for single strategy\n\n Code optimization for a common case.\n\n Will cook in 'next'.\n\n\n* cc/upload-pack-data (2020-05-18) 13 commits\n - upload-pack: use upload_pack_data fields in receive_needs()\n - upload-pack: pass upload_pack_data to create_pack_file()\n - upload-pack: remove static variable 'stateless_rpc'\n - upload-pack: pass upload_pack_data to check_non_tip()\n - upload-pack: pass upload_pack_data to send_ref()\n - upload-pack: move symref to upload_pack_data\n - upload-pack: use upload_pack_data writer in receive_needs()\n - upload-pack: pass upload_pack_data to receive_needs()\n - upload-pack: pass upload_pack_data to get_common_commits()\n - upload-pack: use 'struct upload_pack_data' in upload_pack()\n - upload-pack: move 'struct upload_pack_data' around\n - upload-pack: move {want,have}_obj to upload_pack_data\n - upload-pack: remove unused 'wants' from upload_pack_data\n\n Code clean-up.\n\n\n* dl/remote-curl-deadlock-fix (2020-05-24) 7 commits\n  (merged to 'next' on 2020-05-26 at 072714ca7f)\n + stateless-connect: send response end packet\n + pkt-line: define PACKET_READ_RESPONSE_END\n + remote-curl: error on incomplete packet\n + pkt-line: extern packet_length()\n + transport: extract common fetch_pack() call\n + remote-curl: remove label indentation\n + remote-curl: fix typo\n\n On-the-wire protocol v2 easily falls into a deadlock between the\n remote-curl helper and the fetch-pack process when the server side\n prematurely throws an error and disconnects.  The communication has\n been updated to make it more robust.\n\n Will cook in 'next'.\n\n\n* jk/ci-only-on-selected-branches (2020-05-18) 1 commit\n  (merged to 'next' on 2020-05-24 at 5f1f5ef66a)\n + ci/config: correct instruction for CI preferences\n\n Dev support.\n\n Will merge to 'master'.\n\n\n* la/diff-relative-config (2020-05-24) 1 commit\n  (merged to 'next' on 2020-05-26 at b4604e6abc)\n + diff: add config option relative\n\n The commands in the \"diff\" family learned to honor \"diff.relative\"\n configuration variable.\n\n Will cook in 'next'.\n\n\n* cb/t4210-illseq-auto-detect (2020-05-18) 2 commits\n  (merged to 'next' on 2020-05-24 at c03b4095fa)\n + t4210: detect REG_ILLSEQ dynamically and skip affected tests\n + t/helper: teach test-regex to report pattern errors (like REG_ILLSEQ)\n\n As FreeBSD is not the only platform whose regexp library reports\n a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that\n automatically and skip the affected tests.\n\n Will cook in 'next'.\n\n\n* bk/p4-prepare-p4-only-fix (2020-05-12) 1 commit\n  (merged to 'next' on 2020-05-24 at c1b4644b04)\n + git-p4.py: fix --prepare-p4-only error with multiple commits\n\n The \"--prepare-p4-only\" option is supposed to stop after replaying\n one changeset, but kept going (by mistake?)\n\n Will cook in 'next'.\n cf. <CAE5ih797YYxsR2H0TA65w9W-1jF4jQLayja_nGjQMGtc=PB6Jw@mail.gmail.com>\n\n\n* jt/curl-verbose-on-trace-curl (2020-05-11) 2 commits\n  (merged to 'next' on 2020-05-11 at 814e31b9d4)\n + http, imap-send: stop using CURLOPT_VERBOSE\n + t5551: test that GIT_TRACE_CURL redacts password\n\n Rewrite support for GIT_CURL_VERBOSE in terms of GIT_TRACE_CURL.\n\n Expecting further work on optionally disabling redacting authinfo\n\n\n* mt/grep-sparse-checkout (2020-05-11) 4 commits\n - config: add setting to ignore sparsity patterns in some cmds\n - grep: honor sparse checkout patterns\n - config: load the correct config.worktree file\n - doc: grep: unify info on configuration variables\n\n \"git grep\" has been tweaked to be limited to the sparse checkout\n paths.\n\n Expecting further polishing.\n cf. <CAHd-oW6BoHkMSAQVquHR+H7=g84VE-qmXGYcDmWwFxuLyqZSzg@mail.gmail.com>\n\n\n* bc/sha-256-part-2 (2020-05-13) 44 commits\n - remote-testgit: adapt for object-format\n - bundle: detect hash algorithm when reading refs\n - t5300: pass --object-format to git index-pack\n - t5703: use object-format serve option\n - t5702: offer an object-format capability in the test\n - t/helper: initialize the repository for test-sha1-array\n - remote-curl: avoid truncating refs with ls-remote\n - t1050: pass algorithm to index-pack when outside repo\n - builtin/index-pack: add option to specify hash algorithm\n - remote-curl: detect algorithm for dumb HTTP by size\n - builtin/ls-remote: initialize repository based on fetch\n - t5500: make hash independent\n - serve: advertise object-format capability for protocol v2\n - connect: parse v2 refs with correct hash algorithm\n - connect: pass full packet reader when parsing v2 refs\n - Documentation/technical: document object-format for protocol v2\n - t1302: expect repo format version 1 for SHA-256\n - builtin/show-index: provide options to determine hash algo\n - t5302: modernize test formatting\n - packfile: compute and use the index CRC offset\n - t3200: mark assertion with SHA1 prerequisite\n - setup: set the_repository's hash algo when checking format\n - fetch-pack: parse and advertise the object-format capability\n - t5704: send object-format capability with SHA-256\n - t5562: pass object-format in synthesized test data\n - builtin/clone: initialize hash algorithm properly\n - remote-curl: implement object-format extensions\n - transport-helper: implement object-format extensions\n - docs: update remote helper docs for object-format extensions\n - builtin/receive-pack: detect when the server doesn't support our hash\n - connect: detect algorithm when fetching refs\n - fetch-pack: detect when the server doesn't support our hash\n - connect: make parse_feature_value extern\n - send-pack: detect when the server doesn't support our hash\n - connect: add function to detect supported v1 hash functions\n - transport: add a hash algorithm member\n - pkt-line: add a member for hash algorithm\n - connect: add function to fetch value of a v2 server capability\n - connect: add function to parse multiple v1 capability values\n - remote: advertise the object-format capability on the server side\n - wrapper: add function to compare strings with different NUL termination\n - connect: have ref processing code take struct packet_reader\n - Documentation: document v1 protocol object-format capability\n - t1050: match object ID paths in a hash-insensitive way\n\n SHA-256 migration work continues.\n\n\n* es/bugreport-shell (2020-05-12) 2 commits\n  (merged to 'next' on 2020-05-24 at 79c5c8308b)\n + bugreport: include user interactive shell\n + help: add shell-path to --build-options\n\n \"git bugreport\" learns to report what shell is in use.\n\n Will cook in 'next'.\n We may want to learn more details than just the path, but\n that can come later.\n cf. <20200512235924.GC6605@camp.crustytoothpaste.net>\n\n\n* ds/line-log-on-bloom (2020-05-11) 5 commits\n  (merged to 'next' on 2020-05-11 at 046d49d455)\n + line-log: integrate with changed-path Bloom filters\n + line-log: try to use generation number-based topo-ordering\n + line-log: more responsive, incremental 'git log -L'\n + t4211-line-log: add tests for parent oids\n + line-log: remove unused fields from 'struct line_log_data'\n\n \"git log -L...\" now takes advantage of the \"which paths are touched\n by this commit?\" info stored in the commit-graph system.\n\n Will cook in 'next'.\n\n\n* tb/commit-graph-no-check-oids (2020-05-18) 8 commits\n  (merged to 'next' on 2020-05-24 at 72bd1063ca)\n + commit-graph: drop COMMIT_GRAPH_WRITE_CHECK_OIDS flag\n + t5318: reorder test below 'graph_read_expect'\n + commit-graph.c: simplify 'fill_oids_from_commits'\n + builtin/commit-graph.c: dereference tags in builtin\n + builtin/commit-graph.c: extract 'read_one_commit()'\n + commit-graph.c: peel refs in 'add_ref_to_set'\n + commit-graph.c: show progress of finding reachable commits\n + commit-graph.c: extract 'refs_cb_data'\n\n Clean-up the commit-graph codepath.\n\n Will cook in 'next'.\n\n\n* jx/proc-receive-hook (2020-05-18) 11 commits\n - doc: add documentation for the proc-receive hook\n - transport: parse report options for tracking refs\n - t5411: test updates of remote-tracking branches\n - receive-pack: new config receive.procReceiveRefs\n - refs.c: refactor to reuse ref_is_hidden()\n - receive-pack: feed report options to post-receive\n - doc: add document for capability report-status-v2\n - New capability \"report-status-v2\" for git-push\n - receive-pack: add new proc-receive hook\n - t5411: add basic test cases for proc-receive hook\n - transport: not report a non-head push as a branch\n\n \"git receive-pack\" that accepts requests by \"git push\" learned to\n outsource most of the ref updates to the new \"proc-receive\" hook.\n\n Needs review.\n\n\n* hn/refs-cleanup (2020-05-20) 6 commits\n  (merged to 'next' on 2020-05-24 at dd9b665698)\n + reftable: define version 2 of the spec to accomodate SHA256\n + reftable: clarify how empty tables should be written\n + reftable: file format documentation\n + refs: improve documentation for ref iterator\n + t: use update-ref and show-ref to reading/writing refs\n + refs.h: clarify reflog iteration order\n (this branch is used by hn/reftable.)\n\n Preliminary clean-ups around refs API, plus file format\n specification documentation for the reftable backend.\n\n Will cook in 'next'.\n\n\n* hn/reftable (2020-05-20) 9 commits\n - Add reftable testing infrastructure\n - vcxproj: adjust for the reftable changes\n - Add GIT_DEBUG_REFS debugging mechanism\n - Reftable support for git-core\n - Add reftable library\n - Add .gitattributes for the reftable/ directory\n - Iterate over the \"refs/\" namespace in for_each_[raw]ref\n - Move REF_LOG_ONLY to refs-internal.h\n - Write pseudorefs through ref backends.\n (this branch uses hn/refs-cleanup.)\n\n A new refs backend \"reftable\" to replace the traditional\n combination of packed-refs files and one-file-per-ref loose refs\n has been implemented and integrated for improved performance and\n atomicity.\n\n Needs review.\n\n--------------------------------------------------\n[Discarded]\n\n* jc/credential-store-file-format-doc (2020-04-27) 1 commit\n . credential-store: document the file format a bit more\n\n Now has become a part of Carlo's credential-store fix patches.\n\n\n* js/ci-skip-on-github-workflow (2020-05-02) 1 commit\n . ci: respect the [skip ci] convention in our GitHub workflow \"CI/PR\"\n\n Allow contributors to mark a branch/push that it does not have to\n be built via GitHub actions, in a way similar to how Travis lets\n them mark the commits with an embedded \"[skip ci]\" string.\n\n Superseded by dd/ci-only-on-selective-branches topic.\n\n\n* dd/ci-only-on-selective-branches (2020-05-05) 2 commits\n - CI: limit GitHub Actions to designated branches\n - SubmittingPatches: advertise GitHub Actions CI\n\n Instead of always building all branches of all forks of our project\n at GitHub via GitHub Actions, only build when branches with known\n and specific names are updated, and also a pull request.\n\n Superseded by jk/ci-only-on-selected-branches\n"},{"id":"398690","messageId":"nycvar.QRO.7.76.6.2005270526280.56@tvgsbejvaqbjf.bet","threadId":"53555","inReplyTo":"xmqqsgfmmt2c.fsf@gitster.c.googlers.com","subject":"jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-05-27T03:27:54Z","receivedAt":"2020-05-27T20:01:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Tue, 26 May 2020, Junio C Hamano wrote:\n\n> * jn/experimental-opts-into-proto-v2 (2020-05-21) 1 commit\n>   (merged to 'next' on 2020-05-24 at 53cd664dfe)\n>  + config: let feature.experimental imply protocol.version=2\n>\n>  \"feature.experimental\" configuration variable is to let volunteers\n>  easily opt into a set of newer features, which use of the v2\n>  transport protocol is now a part of.\n>\n>  Will cook in 'next'.\n\nGiven that the `feature.experimental` option is supposed to increase\ntesting in the wild, sort of `next` but for users rather than developers\nwho build their own Git, could we maybe integrate this into v2.27.0,\nstill?\n\nThanks,\nDscho\n"},{"id":"398698","messageId":"xmqq1rn5kpzi.fsf@gitster.c.googlers.com","threadId":"53555","inReplyTo":"nycvar.QRO.7.76.6.2005270526280.56@tvgsbejvaqbjf.bet","subject":"Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-27T21:49:37Z","receivedAt":"2020-05-27T21:49:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Tue, 26 May 2020, Junio C Hamano wrote:\n>\n>> * jn/experimental-opts-into-proto-v2 (2020-05-21) 1 commit\n>>   (merged to 'next' on 2020-05-24 at 53cd664dfe)\n>>  + config: let feature.experimental imply protocol.version=2\n>>\n>>  \"feature.experimental\" configuration variable is to let volunteers\n>>  easily opt into a set of newer features, which use of the v2\n>>  transport protocol is now a part of.\n>>\n>>  Will cook in 'next'.\n>\n> Given that the `feature.experimental` option is supposed to increase\n> testing in the wild, sort of `next` but for users rather than developers\n> who build their own Git, could we maybe integrate this into v2.27.0,\n> still?\n\nI have been wondering about the same thing, and if it were not using\nits own custom way to read the configuration, it would have been a\nnon-brainer to merge it down before the release.  But this late in\nthe cycle, I'd rather not.\n\nThanks.\n"},{"id":"398711","messageId":"20200527235808.GD56118@google.com","threadId":"53555","inReplyTo":"xmqq1rn5kpzi.fsf@gitster.c.googlers.com","subject":"Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2020-05-27T23:58:08Z","receivedAt":"2020-05-27T23:58:13Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJunio C Hamano wrote:\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>> On Tue, 26 May 2020, Junio C Hamano wrote:\n\n>>> * jn/experimental-opts-into-proto-v2 (2020-05-21) 1 commit\n>>>   (merged to 'next' on 2020-05-24 at 53cd664dfe)\n>>>  + config: let feature.experimental imply protocol.version=2\n>>>\n>>>  \"feature.experimental\" configuration variable is to let volunteers\n>>>  easily opt into a set of newer features, which use of the v2\n>>>  transport protocol is now a part of.\n>>>\n>>>  Will cook in 'next'.\n>>\n>> Given that the `feature.experimental` option is supposed to increase\n>> testing in the wild, sort of `next` but for users rather than developers\n>> who build their own Git, could we maybe integrate this into v2.27.0,\n>> still?\n\nYes, that was my hope when writing it.\n\n> I have been wondering about the same thing, and if it were not using\n> its own custom way to read the configuration, it would have been a\n> non-brainer to merge it down before the release.\n\nHm, do you have more detail about this?  git_config_get_bool feels\nvery standard and non-custom.\n\nDo you mean that you would like it to go in repo-settings.c?\n\n>                                                   But this late in\n> the cycle, I'd rather not.\n\nSure, I can understand.\n\nWould this be something to put on \"master\" soon after the release?\n\nDscho, do you think it would be useful for downstreams such as Debian\nto apply it?  (For Debian in particular, it's not hard to get \"next\"\nfrom experimental, so maybe not.)\n\nThanks,\nJonathan\n"},{"id":"398712","messageId":"xmqqeer46g9l.fsf@gitster.c.googlers.com","threadId":"53555","inReplyTo":"20200527235808.GD56118@google.com","subject":"Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-28T00:43:18Z","receivedAt":"2020-05-28T00:43:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>> I have been wondering about the same thing, and if it were not using\n>> its own custom way to read the configuration, it would have been a\n>> non-brainer to merge it down before the release.\n>\n> Hm, do you have more detail about this?  git_config_get_bool feels\n> very standard and non-custom.\n>\n> Do you mean that you would like it to go in repo-settings.c?\n\nNo.  I fully accept your reasoning in the proposed log message why a\nhandcrafted query to the config system is done in the location the\npatch adds a call.  There is nothing wrong with the patch.\n\nBut that means that the way it uses the \"experimental\" variable is\ndifferent from the battle-tested way it has been used, which makes\nit less than \"non-brainer\".  It may not be risky after all, but\nstill.  This late in the cycle, the fewer things we need to worry\nabout, the better.\n>\n>>                                                   But this late in\n>> the cycle, I'd rather not.\n>\n> Sure, I can understand.\n>\n> Would this be something to put on \"master\" soon after the release?\n\nThat was exactly what I had in mind.\n\n"},{"id":"398730","messageId":"nycvar.QRO.7.76.6.2005272159570.56@tvgsbejvaqbjf.bet","threadId":"53555","inReplyTo":"xmqqeer46g9l.fsf@gitster.c.googlers.com","subject":"Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-05-27T20:05:28Z","receivedAt":"2020-05-28T12:39:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 27 May 2020, Junio C Hamano wrote:\n\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n>\n> >> I have been wondering about the same thing, and if it were not using\n> >> its own custom way to read the configuration, it would have been a\n> >> non-brainer to merge it down before the release.\n> >\n> > Hm, do you have more detail about this?  git_config_get_bool feels\n> > very standard and non-custom.\n> >\n> > Do you mean that you would like it to go in repo-settings.c?\n>\n> No.  I fully accept your reasoning in the proposed log message why a\n> handcrafted query to the config system is done in the location the\n> patch adds a call.\n\nNow, I apologize. I had not reviewed the patch, and only just read it.\n\nI agree that it is a bit unfortunate that it uses such a non-standard way\nthat hard-codes \"feature.experimental\" in a different place than\nrepo-settings.c.\n\nAnd I have to admit that the `git ls-remote` example does not really\nconvince me that it makes sense to go a different route than all other\nexperimental options. It makes it unnecessarily hard to gather the list of\nfeatures enabled via `features.experimental = true`.\n\nHad it been a patch to repo-settings.c, I would now have tried to lobby\nfor including it into v2.27.0, but as it is, I fully agree with your\nreasoning to just leave it out.\n\nCiao,\nDscho\n"},{"id":"398738","messageId":"xmqq5zcg5db4.fsf@gitster.c.googlers.com","threadId":"53555","inReplyTo":"nycvar.QRO.7.76.6.2005272159570.56@tvgsbejvaqbjf.bet","subject":"Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-28T14:44:47Z","receivedAt":"2020-05-28T14:44:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> No.  I fully accept your reasoning in the proposed log message why a\n>> handcrafted query to the config system is done in the location the\n>> patch adds a call.\n>\n> Now, I apologize. I had not reviewed the patch, and only just read it.\n>\n> I agree that it is a bit unfortunate that it uses such a non-standard way\n> that hard-codes \"feature.experimental\" in a different place than\n> repo-settings.c.\n\nYou make it sound like it was a choice made by the implementation,\nbut (1) a \"non-standard\" way may not have to stay non-standard\nforever (there may be many more experimental features that are not\ntied to a specific repository in the future), and (2) the patch\nneeds to do it in a way that is not tied to a single repository\nbecause it is not at per-repository level decision.  As long as we\nare aware of this limitation caused by the current \"experimental\"\narrangement that is tied to a repository and can work towards\nextending it to support this new use case in the future, I do not\nthink it is unfortunate at all.\n\n> Had it been a patch to repo-settings.c, I would now have tried to lobby\n> for including it into v2.27.0, but as it is, I fully agree with your\n> reasoning to just leave it out.\n\nNo need to apologize for raising it as an issue---hearing from those\nwith different risk tolerance from time to time is a good way to\ncalibrate my own.\n\nThanks.\n"}]}