{"thread":{"id":"53610","subject":"What's cooking in git.git (Jun 2020, #01; Wed, 3)","startedAt":"2020-06-03T20:59:54Z","lastAt":"2020-06-07T06:28:15Z","messageCount":10,"participants":["Junio C Hamano","Elijah Newren","Christian Couder","brian m. carlson","Philip Oakley","Kaartic Sivaraam"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"399092","messageId":"xmqqlfl3rhl0.fsf@gitster.c.googlers.com","threadId":"53610","inReplyTo":null,"subject":"What's cooking in git.git (Jun 2020, #01; Wed, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-03T20:59:39Z","receivedAt":"2020-06-03T20:59:54Z","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 has been tagged, and the first batch of topics (including\nthe \"throw protocol v2 to the experimental group of features\" thing)\nhave been merged to the 'master' branch.  I'm planning to rewind the\ntip of 'next' in a not-so-distant future.\n\nSeeing a handful of regression reports [*] immediately after a\nfeature release is made gives me a mixed feeling: people are eager\nenough to help by reporting issues they encounter, but there are not\nenough people who are eager enough to help by testing the tip of\n'master' before the release.  Are there things we can do to help\nthem become early adopters so that they do not have to scramble\nafter the release?\n\n    * sparse-checkout\n    cf. <CAD3+_6CUX0RPr-dgfUnfGDNNfqu80SYCskioYnu=MS6aJv2dEQ@mail.gmail.com>\n\n    * untracked with pathspec\n    cf. <CAJmdR_pG74x0Zn43MSm7zXNcoitqjjOy+WnhyGBW+oFjVFLbRQ@mail.gmail.com>\n\n    * shallow point adjustment\n    cf. <20200603034213.GB253041@google.com>\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* 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\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 cf. <CAE5ih797YYxsR2H0TA65w9W-1jF4jQLayja_nGjQMGtc=PB6Jw@mail.gmail.com>\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\n* en/fast-import-looser-date (2020-05-31) 1 commit\n  (merged to 'next' on 2020-05-31 at 49de9c07c5)\n + fast-import: add new --date-format=raw-permissive format\n\n Some repositories in the wild have commits that record nonsense\n committer timezone (e.g. rails.git); \"git fast-import\" learned an\n option to pass these nonsense timestamps intact to allow recreating\n existing repositories as-is.\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\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\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\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\n* mt/zsh-completion-optim (2020-05-28) 1 commit\n  (merged to 'next' on 2020-05-31 at f5d02a5498)\n + completion: use native ZSH array pattern matching\n\n Command line completion (incontrib/) update.\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--------------------------------------------------\n[New Topics]\n\n* jk/diff-memuse-optim-with-stat-unmatch (2020-06-02) 1 commit\n - diff: discard blob data from stat-unmatched pairs\n\n Reduce memory usage during \"diff --quiet\" in a worktree with too\n many stat-unmatched paths.\n\n Will merge to 'next'.\n\n\n* js/reflog-anonymize-for-clone-and-fetch (2020-06-02) 1 commit\n - clone/fetch: anonymize URLs in the reflog\n\n The reflog entries for \"git clone\" and \"git fetch\" did not\n anonymize the URL they operated on.\n\n Will merge to 'next'.\n\n\n* tb/t5318-cleanup (2020-06-02) 2 commits\n - t5318: test that '--stdin-commits' respects '--[no-]progress'\n - t5318: use 'test_must_be_empty'\n\n Code cleanup.\n\n Almost there.\n cf. <20200602180403.GA4791@szeder.dev>\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* 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 Expecting a reroll.\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* cc/upload-pack-data-2 (2020-06-02) 14 commits\n - fixup! upload-pack: change multi_ack to an enum\n - upload-pack: move pack_objects_hook to upload_pack_data\n - upload-pack: move allow_sideband_all to upload_pack_data\n - upload-pack: move allow_ref_in_want to upload_pack_data\n - upload-pack: move allow_filter to upload_pack_data\n - upload-pack: move keepalive to upload_pack_data\n - upload-pack: pass upload_pack_data to upload_pack_config()\n - upload-pack: change multi_ack to an enum\n - upload-pack: move multi_ack to upload_pack_data\n - upload-pack: move filter_capability_requested to upload_pack_data\n - upload-pack: move use_sideband to upload_pack_data\n - upload-pack: move static vars to upload_pack_data\n - upload-pack: annotate upload_pack_data fields\n - upload-pack: actually use some upload_pack_data bitfields\n (this branch uses cc/upload-pack-data.)\n\n Further code clean-up.\n\n Almost there.\n\n\n* js/checkout-p-new-file (2020-05-27) 1 commit\n  (merged to 'next' on 2020-05-31 at 017c325bf6)\n + checkout -p: handle new files correctly\n\n \"git checkout -p\" did not handle a newly added path at all.\n\n Will merge to 'master'.\n\n\n* xl/upgrade-repo-format (2020-05-29) 1 commit\n - fetch: allow adding a filter after initial clone\n\n Allow runtime upgrade of the repository format version, which needs\n to be done carefully.\n\n Almost there.\n\n\n* jk/complete-git-switch (2020-05-28) 16 commits\n - completion: improve handling of --orphan option of switch/checkout\n - completion: improve handling of -c/-C and -b/-B in switch/checkout\n - completion: improve handling of --track in switch/checkout\n - completion: improve handling of --detach in checkout\n - completion: improve completion for git switch with no options\n - completion: improve handling of DWIM mode for switch/checkout\n - completion: perform DWIM logic directly in __git_complete_refs\n - completion: extract function __git_dwim_remote_heads\n - completion: replace overloaded track term for __git_complete_refs\n - completion: add tests showing subpar switch/checkout --orphan logic\n - completion: add tests showing subpar -c/C argument completion\n - completion: add tests showing subpar -c/-C startpoint completion\n - completion: add tests showing subpar switch/checkout --track logic\n - completion: add tests showing subar checkout --detach logic\n - completion: add tests showing subpar DWIM logic for switch/checkout\n - completion: add test showing subpar git switch completion\n\n The command line completion (in contrib/) learned to complete\n options that the \"git switch\" command takes.\n\n\n* en/sparse-with-submodule-doc (2020-05-25) 1 commit\n - git-sparse-checkout: clarify interactions with submodules\n\n The effect of sparse checkout settings on submodules is documented.\n\n Needs review.\n\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 merge to 'master'.\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 merge to 'master'.\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 merge to 'master'.\n\n\n* ss/submodule-set-branch-in-c (2020-06-02) 1 commit\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 Almost there.\n cf. <1b851e49-3bb1-3b59-7f24-b903c5514391@gmail.com>\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 merge to 'master'.\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* pw/rebase-i-more-options (2020-05-27) 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 Not quite\n cf. <nycvar.QRO.7.76.6.2005290437350.56@tvgsbejvaqbjf.bet>\n\n\n* cc/upload-pack-data (2020-05-18) 13 commits\n  (merged to 'next' on 2020-05-29 at 66008d9209)\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 (this branch is used by cc/upload-pack-data-2.)\n\n Code clean-up.\n\n Will merge to 'master'.\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 merge to 'master'.\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 merge to 'master'.\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-06-02) 6 commits\n - git.c: fix sparse warning\n - config: add setting to ignore sparsity patterns in some cmds\n - grep: honor sparse checkout patterns\n - config: correctly read worktree configs in submodules\n - t/helper/test-config: return exit codes consistently\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 a reroll.\n cf. <cover.1590627264.git.matheus.bernardino@usp.br>\n cf. <CABPp-BFsCPPNOZ92JQRJeGyNd0e-TCW-LcLyr0i_+VSQJP+GCg@mail.gmail.com>\n\n\n* bc/sha-256-part-2 (2020-05-27) 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 - t5704: send object-format capability with SHA-256\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 - 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 merge to 'master'.\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 merge to 'master'.\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 merge to 'master'.\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-27) 7 commits\n  (merged to 'next' on 2020-05-27 at aada2199e1)\n + reftable doc: use link: and urlencode to avoid dead links\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 merge to 'master' after squashing the fix in.\n We probably would want to squash the fix at the tip to an earlier\n step when we rewind the 'next' branch.\n\n\n* hn/reftable (2020-05-28) 13 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 . Treat REVERT_HEAD as a pseudo ref\n . Treat CHERRY_PICK_HEAD as a pseudo ref\n . Treat BISECT_HEAD as a pseudo ref\n . Make refs_ref_exists public\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 Not quite--does not pass tests by itself.\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":"399106","messageId":"CABPp-BH=SqT5v=CnuPm+6Sqy+1tP=72Wx_oCKs+DxJcdKzwgFA@mail.gmail.com","threadId":"53610","inReplyTo":"xmqqlfl3rhl0.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-06-04T08:14:28Z","receivedAt":"2020-06-04T08:14:42Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Wed, Jun 3, 2020 at 2:01 PM Junio C Hamano <gitster@pobox.com> wrote:\n> Seeing a handful of regression reports [*] immediately after a\n> feature release is made gives me a mixed feeling: people are eager\n> enough to help by reporting issues they encounter, but there are not\n> enough people who are eager enough to help by testing the tip of\n> 'master' before the release.  Are there things we can do to help\n> them become early adopters so that they do not have to scramble\n> after the release?\n\nThat's very diplomatically worded, but perhaps let me peel back that\ndeflection layer a bit and be more direct...\n\nA disproportionate number of regressions that we've had in recent\nreleases have traced back to me.  2 of the 3 regressions from 2.27 do.\nIn the 2.26 release, we had a whole pile of regressions with rebase\ndue to the change in the default backend, which came from me.  And,\nwe've also had a bunch of \"fun\" with dir.c in _every_ _single_\n_release_ (to the best of my memory anyway) since I got my foot caught\nin that unrelenting trap[1], including 1 of the 3 reported regressions\nin this latest release.  The regression reports after releases have\nbeen weighing on me too; I was thinking about it a fair bit last week\nas well as this week.\n\n[1] https://kernel.googlesource.com/pub/scm/git/git/+/8d92fb292706fd8d13cfe55353b2ec9345153a3e\n\n\nNow, it's possible these regressions could just be a reflection of the\nfact that I'm focusing more on fixing inconsistent behaviors rather\nthan adding new features, which is a type of work where it's much\nharder to avoid fallout and reported issues.  But it's also quite\npossible that I'm going about these cleanups wrong or at least\nsuboptimally.  I'm open for suggestions of what I should change, or\neven experiments to try.\n\nRecent attempts I've made to make things better: (1) I have in the\npast month or so gotten a company internal distribution of git\nstarted, with a growing number of users.  This distribution uses\npre-release versions of git, mostly off master so far though I'm\nconsidering moving to 'next' for it.  (2) I pushed hard during 2.27\nfor the dir.c changes to either merge early in that cycle or wait\nuntil early in the 2.28 cycle -- hoping that an early merge would give\nmore time for testing.  (This was an attempt to learn from the 2.26\nrebase issues, since that merged late in the 2.26 cycle).\n\nAny other ideas I should try?\n\n\nThanks,\nElijah\n"},{"id":"399113","messageId":"CAP8UFD0V+=tq8CGFk_Mz+N=HjRtkhkMbX9Cy2-=WfHL8wrj6=Q@mail.gmail.com","threadId":"53610","inReplyTo":"CABPp-BH=SqT5v=CnuPm+6Sqy+1tP=72Wx_oCKs+DxJcdKzwgFA@mail.gmail.com","subject":"Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2020-06-04T14:32:37Z","receivedAt":"2020-06-04T14:32:52Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Jun 4, 2020 at 11:20 AM Elijah Newren <newren@gmail.com> wrote:\n\n> On Wed, Jun 3, 2020 at 2:01 PM Junio C Hamano <gitster@pobox.com> wrote:\n\n> Now, it's possible these regressions could just be a reflection of the\n> fact that I'm focusing more on fixing inconsistent behaviors\n\nI agree with that. It's very difficult to implement big changes like\nchanging the rebase backend without any regression at all.\n\n> rather\n> than adding new features, which is a type of work where it's much\n> harder to avoid fallout and reported issues.  But it's also quite\n> possible that I'm going about these cleanups wrong or at least\n> suboptimally.  I'm open for suggestions of what I should change, or\n> even experiments to try.\n\nIt's possible to add more tests, but it's not possible to test\neverything and it's hard to know it the tests we add are effective at\navoiding regressions. Not sure we can do much better.\n\n> Recent attempts I've made to make things better: (1) I have in the\n> past month or so gotten a company internal distribution of git\n> started, with a growing number of users.  This distribution uses\n> pre-release versions of git, mostly off master so far though I'm\n> considering moving to 'next' for it.\n\nGreat! At GitLab we are slowly moving toward something like that, but\nnot there yet.\n\n> (2) I pushed hard during 2.27\n> for the dir.c changes to either merge early in that cycle or wait\n> until early in the 2.28 cycle -- hoping that an early merge would give\n> more time for testing.  (This was an attempt to learn from the 2.26\n> rebase issues, since that merged late in the 2.26 cycle).\n\nThat's a good idea.\n\nNow to go back to Junio's question:\n\n> ... people are eager\n> enough to help by reporting issues they encounter, but there are not\n> enough people who are eager enough to help by testing the tip of\n> 'master' before the release. Are there things we can do to help\n> them become early adopters so that they do not have to scramble\n> after the release?\n\nYeah, I agree that increasing the number of early adopters could be\nthe best way to avoid regressions report just after the release.\n\nMaybe we could just ask people to test rc releases or 'master' in Git\nRev News? It might work better if someone wrote a small article about\nwhat is coming in the next release before asking to test. Then there\nis the issue of making it easier to build Git and to understand and\nfix build issues. We could also perhaps coordinate Git Rev News\neditions and Git releases, so that the editions are published for\nexample between rc-1 and rc-2  releases.\n\nBest,\nChristian.\n"},{"id":"399115","messageId":"CAP8UFD2x_j9Ne-YQes_Q9B+MAgXgM7+w2xSZpMVxNj3wnf0Rfg@mail.gmail.com","threadId":"53610","inReplyTo":"CAP8UFD0V+=tq8CGFk_Mz+N=HjRtkhkMbX9Cy2-=WfHL8wrj6=Q@mail.gmail.com","subject":"Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2020-06-04T14:39:46Z","receivedAt":"2020-06-04T14:40:01Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Jun 4, 2020 at 4:32 PM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> Maybe we could just ask people to test rc releases or 'master' in Git\n> Rev News? It might work better if someone wrote a small article about\n> what is coming in the next release before asking to test.\n\nSuch articles and asking users to test more could also be done on\nGitLab's, GitHub's, etc, corporate blogs or on Git developer's blogs\ntoo. The content of such articles could also be shared between\ndifferent company blogs and Git Rev News to reach as many users as\npossible.\n"},{"id":"399117","messageId":"xmqqh7vqrimm.fsf@gitster.c.googlers.com","threadId":"53610","inReplyTo":"CABPp-BH=SqT5v=CnuPm+6Sqy+1tP=72Wx_oCKs+DxJcdKzwgFA@mail.gmail.com","subject":"Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-04T14:49:21Z","receivedAt":"2020-06-04T14:49:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n\n> On Wed, Jun 3, 2020 at 2:01 PM Junio C Hamano <gitster@pobox.com> wrote:\n>> Seeing a handful of regression reports [*] immediately after a\n>> feature release is made gives me a mixed feeling: people are eager\n>> enough to help by reporting issues they encounter, but there are not\n>> enough people who are eager enough to help by testing the tip of\n>> 'master' before the release.  Are there things we can do to help\n>> them become early adopters so that they do not have to scramble\n>> after the release?\n>\n> That's very diplomatically worded, but perhaps let me peel back that\n> deflection layer a bit and be more direct...\n\nSorry, but you are reading too much into it.\n\nI am not worried about individual bugs; bugs happen and that is an\ninevitable part of development.  I have enough confidence in our\ndevelopers to feel that we can promptly fix a regression once an\nissue is raised and clarified sufficiently to be actionable.\n\n> Now, it's possible these regressions could just be a reflection of the\n> fact that I'm focusing more on fixing inconsistent behaviors rather\n> than adding new features, which is a type of work where it's much\n> harder to avoid fallout and reported issues.\n\nYes, and as I said already, bugs happen and they tend to happen to\nthose who touch the trickiest part of the existing code---it is\ninevitable.  It is OK to be initially buggy as long as we can fix\nbreakages promptly.\n\nI am however worried about how the issues often are not raised until\na regression hits a tagged version.  As a piece of software gets\nused more and more widely, it would be used in more and more\ndifferent ways, and some of these ways may not be covered by\ndevelopers' minds; by definition, some regressions are noticed only\nafter a new version hits end users' hands.\n\nBasing in-house releases a Git developer has control over on\n'master' or 'next' would reach audiences that the Git developer has\naccess to, and as long as the in-house users use Git sufficiently\ndifferently from the Git developer (is that a realistic expectation,\nthough?), we'd gain more coverage before a tagged release happens\nthat way.  Basing the version placed in a distro's 'testing' track\non 'master' or 'next' may give us even wider exposure but it would\nbe much harder to arrange, I am afraid.\n\nPeople from time to time suggest to merge trickier topics early in\nthe cycle, and in principle I do agree that it may not be a bad\nidea, but given that we do not have enough folks on 'master', I am\nnot so sure how much that would actially help.\n\nThanks.\n\n\n"},{"id":"399156","messageId":"20200604234145.GA6569@camp.crustytoothpaste.net","threadId":"53610","inReplyTo":"xmqqlfl3rhl0.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-06-04T23:41:45Z","receivedAt":"2020-06-04T23:41:53Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-06-03 at 20:59:39, Junio C Hamano wrote:\n> 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\n> the integration branches, but I am still holding onto them.\n> \n> Git 2.27 has been tagged, and the first batch of topics (including\n> the \"throw protocol v2 to the experimental group of features\" thing)\n> have been merged to the 'master' branch.  I'm planning to rewind the\n> tip of 'next' in a not-so-distant future.\n> \n> Seeing a handful of regression reports [*] immediately after a\n> feature release is made gives me a mixed feeling: people are eager\n> enough to help by reporting issues they encounter, but there are not\n> enough people who are eager enough to help by testing the tip of\n> 'master' before the release.  Are there things we can do to help\n> them become early adopters so that they do not have to scramble\n> after the release?\n\nFor folks that are using Debian, Jonathan Nieder kindly keeps Debian\nexperimental generally within about a week or so of the latest next\n(with the -rc merged into it during that period).  (As of today, the\nversion is from 2020-05-31.)  This is usually what I use and it's\nreasonably stable, so folks who want to test things may find it\nconvenient to rely on existing packages.\n\nI don't happen to use a lot of these features, so I don't notice any\nissues with them, but I have seen issues in the past with other features\nand reported them.  Maybe if there are companies with folks who are\nusing sparse-checkout and similar features it may be helpful to build\nand deploy an -rc or two if they have some way of standard deployments\nto developer machines (which I admit most places don't).\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"399160","messageId":"CABPp-BFLUZvycq_o6mPcx3ZQkeQy79nQ_mGD3B+JLzBwb6ER=g@mail.gmail.com","threadId":"53610","inReplyTo":"xmqqh7vqrimm.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-06-05T01:46:01Z","receivedAt":"2020-06-05T01:46:16Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Jun 4, 2020 at 7:49 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Elijah Newren <newren@gmail.com> writes:\n>\n> > On Wed, Jun 3, 2020 at 2:01 PM Junio C Hamano <gitster@pobox.com> wrote:\n> >> Seeing a handful of regression reports [*] immediately after a\n> >> feature release is made gives me a mixed feeling: people are eager\n> >> enough to help by reporting issues they encounter, but there are not\n> >> enough people who are eager enough to help by testing the tip of\n> >> 'master' before the release.  Are there things we can do to help\n> >> them become early adopters so that they do not have to scramble\n> >> after the release?\n> >\n> > That's very diplomatically worded, but perhaps let me peel back that\n> > deflection layer a bit and be more direct...\n>\n> Sorry, but you are reading too much into it.\n>\n> I am not worried about individual bugs; bugs happen and that is an\n> inevitable part of development.  I have enough confidence in our\n> developers to feel that we can promptly fix a regression once an\n> issue is raised and clarified sufficiently to be actionable.\n>\n> > Now, it's possible these regressions could just be a reflection of the\n> > fact that I'm focusing more on fixing inconsistent behaviors rather\n> > than adding new features, which is a type of work where it's much\n> > harder to avoid fallout and reported issues.\n>\n> Yes, and as I said already, bugs happen and they tend to happen to\n> those who touch the trickiest part of the existing code---it is\n> inevitable.  It is OK to be initially buggy as long as we can fix\n> breakages promptly.\n\nThanks, I'm glad you're not worried about that.\n\n2.26 drained me pretty bad, enough that I was somewhat apprehensive of\n2.27 being released.  Then two quick reports after 2.27 was released\nwas quickly filling me with dread and had me considering how I could\nchange it.  Maybe I was just in an overly worried and drained mindset\nwhen your email happened to arrive.\n\n> I am however worried about how the issues often are not raised until\n> a regression hits a tagged version.  As a piece of software gets\n> used more and more widely, it would be used in more and more\n> different ways, and some of these ways may not be covered by\n> developers' minds; by definition, some regressions are noticed only\n> after a new version hits end users' hands.\n>\n> Basing in-house releases a Git developer has control over on\n> 'master' or 'next' would reach audiences that the Git developer has\n> access to, and as long as the in-house users use Git sufficiently\n> differently from the Git developer (is that a realistic expectation,\n> though?), we'd gain more coverage before a tagged release happens\n> that way.  Basing the version placed in a distro's 'testing' track\n> on 'master' or 'next' may give us even wider exposure but it would\n> be much harder to arrange, I am afraid.\n>\n> People from time to time suggest to merge trickier topics early in\n> the cycle, and in principle I do agree that it may not be a bad\n> idea, but given that we do not have enough folks on 'master', I am\n> not so sure how much that would actially help.\n\nTrue, though I thought jrnieder's reports from Google's internal\ntesting were pretty cool; they caught some important bugs even if they\ndidn't catch everything.  The more of us doing stuff like that, the\nbetter off we'll be, even if it's not as good as getting on a distro's\ntesting track.\n\nAnother consideration we could make is just scheduling .1 releases\nautomatically, and not limiting them to security fixes but instead\nconsidering the same kinds of things that would be allowed around the\ntime of -rc1 or -rc2.  I still want to push to make the quality of .0\nreleases as high as we can, but given that human nature seems to lean\ntowards avoiding things until they are labelled as official, and since\nwe benefit from that wider feedback, maybe we adjust slightly to take\nadvantage of natural behavior and do .1 releases?  Anyway, just a\nthought.\n"},{"id":"399231","messageId":"ca05688f-4f03-97b4-7f88-a4fc89bc119a@iee.email","threadId":"53610","inReplyTo":"CABPp-BFLUZvycq_o6mPcx3ZQkeQy79nQ_mGD3B+JLzBwb6ER=g@mail.gmail.com","subject":"Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-06-06T13:57:48Z","receivedAt":"2020-06-06T13:57:54Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 05/06/2020 02:46, Elijah Newren wrote:\n> Another consideration we could make is just scheduling .1 releases\n> automatically, and not limiting them to security fixes but instead\n> considering the same kinds of things that would be allowed around the\n> time of -rc1 or -rc2.  I still want to push to make the quality of .0\n> releases as high as we can, but given that human nature seems to lean\n> towards avoiding things until they are labelled as official, and since\n> we benefit from that wider feedback, maybe we adjust slightly to take\n> advantage of natural behavior and do .1 releases?  Anyway, just a\n> thought.\n\nMaybe simply tag the current master every 2 weeks of the cycle (.wk2,\n.wk4, wk6), as appropriate, just to give potential users/testers a stake\nin the ground to reference to.\n\nOr maybe a 'mid cycle' .mc1 release for a similar 'nudge' effect [1] of\n'try this one'.\n\nPhilip\n\n[1] https://en.wikipedia.org/wiki/Nudge_theory\n"},{"id":"399232","messageId":"8e479e02-81c5-6329-ff1f-304b1cd4e292@gmail.com","threadId":"53610","inReplyTo":"CAP8UFD0V+=tq8CGFk_Mz+N=HjRtkhkMbX9Cy2-=WfHL8wrj6=Q@mail.gmail.com","subject":"Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2020-06-06T14:53:47Z","receivedAt":"2020-06-06T14:53:54Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On 04-06-2020 20:02, Christian Couder wrote:\n>\n> Now to go back to Junio's question:\n> \n>> ... people are eager\n>> enough to help by reporting issues they encounter, but there are not\n>> enough people who are eager enough to help by testing the tip of\n>> 'master' before the release. Are there things we can do to help\n>> them become early adopters so that they do not have to scramble\n>> after the release?\n> \n> Yeah, I agree that increasing the number of early adopters could be\n> the best way to avoid regressions report just after the release.\n> \n> Maybe we could just ask people to test rc releases or 'master' in Git\n> Rev News?\n\nThat sounds like a good idea.\n\n> It might work better if someone wrote a small article about\n> what is coming in the next release before asking to test.\n\nI think writing an article wouldn't need much effort thanks to\nthe wonderful summaries of the topics already found in the '-rc'\nrelease e-mails. It might need curation as there would be a lot\nof topics.\n\n> Then there\n> is the issue of making it easier to build Git and to understand and\n> fix build issues.\n\nYeah, that would be nice. As a first step we could link to steps for\nbuilding Git from the hypothetical article about the '-rc'.\nThe \"Install Dependencies\" section of MyFirstContribution is\nan option[1].\n\n[1]: https://git-scm.com/docs/MyFirstContribution#dependencies\n\n> We could also perhaps coordinate Git Rev News\n> editions and Git releases, so that the editions are published for\n> example between rc-1 and rc-2  releases.\n>\n\nThat would be necessary. Though, I'm wondering how the eight to ten\nweek feature release cycle of Git and monthly frequency of Rev News\nwould play along. This might need some thought.\n\n-- \nSivaraam\n"},{"id":"399239","messageId":"CAP8UFD3O=+FyY4TrwjDdwGBAEEK1QPPzMZ0WSEL8UM_cecBgoQ@mail.gmail.com","threadId":"53610","inReplyTo":"8e479e02-81c5-6329-ff1f-304b1cd4e292@gmail.com","subject":"Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2020-06-07T06:27:59Z","receivedAt":"2020-06-07T06:28:15Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sat, Jun 6, 2020 at 4:53 PM Kaartic Sivaraam\n<kaartic.sivaraam@gmail.com> wrote:\n>\n> On 04-06-2020 20:02, Christian Couder wrote:\n\n> > Then there\n> > is the issue of making it easier to build Git and to understand and\n> > fix build issues.\n>\n> Yeah, that would be nice. As a first step we could link to steps for\n> building Git from the hypothetical article about the '-rc'.\n> The \"Install Dependencies\" section of MyFirstContribution is\n> an option[1].\n>\n> [1]: https://git-scm.com/docs/MyFirstContribution#dependencies\n\nA related issue (https://github.com/git/git.github.io/issues/435) was\nopened recently about https://git.github.io/ not helping with\ndebugging Git, so there is a new page to try to help with this. You\ncan see it at:\n\nhttps://git.github.io/Hacking-Git/\n\nand:\n\nhttps://github.com/git/git.github.io/blob/master/Hacking-Git.md\n"}]}