{"thread":{"id":"53978","subject":"What's cooking in git.git (Aug 2020, #01; Mon, 3)","startedAt":"2020-08-04T05:35:49Z","lastAt":"2020-08-17T17:27:38Z","messageCount":15,"participants":["Junio C Hamano","Jeff King","Jiang Xin","Johannes Schindelin","Sibi Siddharthan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"402796","messageId":"xmqq8sevt1lf.fsf@gitster.c.googlers.com","threadId":"53978","inReplyTo":null,"subject":"What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-04T05:35:40Z","receivedAt":"2020-08-04T05:35:49Z","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 '-' are\nonly in 'seen' (formerly 'pu'---proposed updates) while commits prefixed\nwith '+' are in 'next'.  The ones marked with '.' do not appear in any of\nthe integration branches, but I am still holding onto them.\n\nSome topics that have been cooking in 'next' during the previous\ncycle, in addition to some fixes to 2.28, have been merged to\n'master', and the tip of 'next' has been rewound.\n\nYou can find the changes described here in the integration branches of the\nrepositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[New Topics]\n\n* en/eol-attrs-gotchas (2020-08-03) 4 commits\n - checkout: support renormalization with checkout -m <paths>\n - merge: make merge.renormalize work for all uses of merge machinery\n - t6038: remove problematic test\n - t6038: make tests fail for the right reason\n\n All \"mergy\" operations that internally use the merge-recursive\n machinery should honor the merge.renormalize configuration, but\n many of them didn't.\n\n Will merge to 'next'.\n\n\n* en/merge-recursive-comment-fixes (2020-08-02) 1 commit\n - merge-recursive: fix unclear and outright wrong comments\n\n Comment fix.\n\n Will merge to 'next'.\n\n\n* es/adjust-subtree-test-for-merge-msg-update (2020-08-03) 1 commit\n - Revert \"contrib: subtree: adjust test to change in fmt-merge-msg\"\n\n Adjust tests in contrib/ to the recent change to fmt-merge-msg.\n\n Will merge to 'next'.\n\n\n* es/worktree-cleanup (2020-07-31) 4 commits\n - worktree: retire special-case normalization of main worktree path\n - worktree: drop bogus and unnecessary path munging\n - worktree: drop unused code from get_linked_worktree()\n - worktree: drop pointless strbuf_release()\n\n Code cleanup around \"worktree\" API implementation.\n\n Will merge to 'next'.\n\n\n* es/worktree-doc-cleanups (2020-08-03) 5 commits\n - git-worktree.txt: link to man pages when citing other Git commands\n - git-worktree.txt: make start of new sentence more obvious\n - git-worktree.txt: fix minor grammatical issues\n - git-worktree.txt: consistently use term \"working tree\"\n - git-worktree.txt: employ fixed-width typeface consistently\n\n Doc cleanup around \"worktree\".\n\n Will merge to 'next'.\n\n\n* ma/t1450-quotefix (2020-08-01) 1 commit\n - t1450: fix quoting of NUL byte when corrupting pack\n\n Test fix.\n\n Will merge to 'next'.\n\n\n* ny/notes-doc-sample-update (2020-08-03) 1 commit\n - docs: improve the example that illustrates git-notes path names\n\n Doc updates.\n\n Will merge to 'next'.\n\n\n* pb/guide-docs (2020-08-02) 4 commits\n - SQUASH???\n - git.txt: add list of guides\n - help: drop usage of 'common' and 'useful' for guides\n - command-list.txt: add missing 'gitcredentials' and 'gitremote-helpers'\n\n Update \"git help guides\" documentation organization.\n\n\n* rs/bisect-oid-to-hex-fix (2020-08-02) 1 commit\n - bisect: use oid_to_hex_r() instead of memcpy()+oid_to_hex()\n\n Code cleanup.\n\n Will merge to 'next'.\n\n\n* rs/more-buffered-io (2020-08-02) 3 commits\n - upload-pack: use buffered I/O to talk to rev-list\n - midx: use buffered I/O to talk to pack-objects\n - connected: use buffered I/O to talk to rev-list\n\n--------------------------------------------------\n[Graduated to 'master']\n\n* ar/help-guides-doc (2020-07-29) 1 commit\n  (merged to 'next' on 2020-07-30 at e4b0370bfa)\n + git-help.txt: fix mentions of option --guides\n\n Doc update.\n\n\n* cc/pretty-contents-size (2020-07-31) 1 commit\n  (merged to 'next' on 2020-07-31 at 0ad958f31d)\n + t6300: fix issues related to %(contents:size)\n\n Brown-paper-bag fix.\n\n\n* en/typofixes (2020-07-28) 2 commits\n  (merged to 'next' on 2020-07-30 at 64776daa9a)\n + hashmap: fix typo in usage docs\n + Remove doubled words in various comments\n\n Typofixes.\n\n\n* hn/reftable (2020-07-31) 1 commit\n  (merged to 'next' on 2020-07-31 at 9e34be957e)\n + refs: move the logic to add \\t to reflog to the files backend\n\n Brown-paper-bag fix.\n\n\n* jb/doc-packfile-name (2020-07-22) 1 commit\n  (merged to 'next' on 2020-07-30 at b46c3f6675)\n + pack-write/docs: update regarding pack naming\n\n Doc update.\n\n\n* jc/fmt-merge-msg-suppress-destination (2020-07-30) 2 commits\n  (merged to 'next' on 2020-07-30 at c44f57f46d)\n + fmt-merge-msg: allow merge destination to be omitted again\n + Revert \"fmt-merge-msg: stop treating `master` specially\"\n\n \"git merge\" learned to selectively omit \" into <branch>\" at the end\n of the title of default merge message with merge.suppressDest\n configuration.\n\n\n* rs/grep-simpler-parse-object-or-die-call (2020-07-28) 1 commit\n  (merged to 'next' on 2020-07-30 at 6d22dd3058)\n + grep: avoid using oid_to_hex() with parse_object_or_die()\n\n Code clean-up.\n\n\n* sg/ci-git-path-fix-with-pyenv (2020-07-23) 1 commit\n  (merged to 'next' on 2020-07-30 at afe304633d)\n + ci: use absolute PYTHON_PATH in the Linux jobs\n\n CI fixup---tests of Python scripts didn't use the version of Git\n that is being tested.\n\n\n* sk/typofixes (2020-07-29) 1 commit\n  (merged to 'next' on 2020-07-30 at c56d9e5313)\n + comment: fix spelling mistakes inside comments\n\n Typofixes.\n\n--------------------------------------------------\n[Stalled]\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 Ejected out of 'seen'; somehow its tests seem to break with clang\n cf. https://travis-ci.org/github/git/git/builds/713443572\n\n\n* mf/submodule-summary-with-correct-repository (2020-06-24) 2 commits\n - submodule: use submodule repository when preparing summary\n - revision: use repository from rev_info when parsing commits\n\n \"git diff/show\" on a change that involves a submodule used to read\n the information on commits in the submodule from a wrong repository\n and gave a wrong information when the commit-graph is involved.\n\n Needs tests.\n\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* mr/bisect-in-c-2 (2020-07-17) 14 commits\n . SQUASH??? do not add new users of git_path_bisect_head()\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: call 'clear_commit_marks_all()' in 'bisect_next_all()'\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: BUG() in cmd_*() on invalid subcommand\n\n Rewrite of the remainder of \"git bisect\" script in C continues.\n\n Needs more work.\n Ejected out of 'seen'; al/bisect-first-parent topic has a bit of\n textual conflict with this topic.\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* jk/log-fp-implies-m (2020-07-29) 7 commits\n  (merged to 'next' on 2020-08-03 at 39fefa6b82)\n + doc/git-log: clarify handling of merge commit diffs\n + doc/git-log: move \"-t\" into diff-options list\n + doc/git-log: drop \"-r\" diff option\n + doc/git-log: move \"Diff Formatting\" from rev-list-options\n + log: enable \"-m\" automatically with \"--first-parent\"\n + revision: add \"--no-diff-merges\" option to counteract \"-m\"\n + log: drop \"--cc implies -m\" logic\n\n Originally merged to 'next' on 2020-08-01\n\n \"git log --first-parent -p\" showed patches only for single-parent\n commits on the first-parent chain; the \"--first-parent\" option has\n been made to imply \"-m\".  Use \"--no-diff-merges\" to restore the\n previous behaviour to omit patches for merge commits.\n\n Waiting for the discussion to settle.\n cf. <87lfivqvgf.fsf@osv.gnss.ru>\n If Sergey wants to send in --diff-merges=(none|<num>|c|cc|all)\n enhancement reasonably soon, I do not mind holding this off for a\n bit longer out of 'master'.\n\n\n* jk/strvec (2020-07-30) 11 commits\n - strvec: rename struct fields\n - strvec: drop argv_array compatibility layer\n - strvec: update documention to avoid argv_array\n - strvec: fix indentation in renamed calls\n - strvec: convert remaining callers away from argv_array name\n - strvec: convert more callers away from argv_array name\n - strvec: convert builtin/ callers away from argv_array name\n - quote: rename sq_dequote_to_argv_array to mention strvec\n - strvec: rename files from argv-array to strvec\n - argv-array: rename to strvec\n - argv-array: use size_t for count and alloc\n (this branch is used by ds/maintenance.)\n\n The argv_array API is useful for not just managing argv but any\n \"vector\" (NULL-terminated array) of strings, and has seen adoption\n to a certain degree.  It has been renamed to \"strvec\" to reduce the\n barrier to adoption.\n\n Will merge to 'next'.\n\n\n* pd/mergetool-nvimdiff (2020-07-29) 2 commits\n - mergetools: add support for nvimdiff (neovim) family\n - mergetool--lib: improve support for vimdiff-style tool variants\n\n The existing backends for \"git mergetool\" based on variants of vim\n have been refactored and then support for \"nvim\" has been added.\n\n\n* al/bisect-first-parent (2020-07-29) 3 commits\n - bisect: combine args passed to find_bisection()\n - bisect: introduce first-parent flag\n - rev-list: allow bisect and first-parent flags\n\n \"git bisect\" learns the \"--first-parent\" option to find the first\n breakage along the first-parent chain.\n\n\n* dd/send-email-config (2020-07-23) 1 commit\n - git-send-email: die if sendmail.* config is set\n\n Stop when \"sendmail.*\" configuration variables are defined, which\n could be a mistaken attempt to define \"sendemail.*\" variables.\n\n\n* jt/pack-objects-prefetch-in-batch (2020-07-21) 2 commits\n  (merged to 'next' on 2020-08-03 at 29424e614d)\n + pack-objects: prefetch objects to be packed\n + pack-objects: refactor to oid_object_info_extended\n\n Originally merged to 'next' on 2020-08-01\n\n While packing many objects in a repository with a promissor remote,\n lazily fetching missing objects from the promissor remote one by\n one may be inefficient---the code now attempts to fetch all the\n missing objects in batch (obviously this won't work for a lazy\n clone that lazily fetches tree objects as you cannot even enumerate\n what blobs are missing until you learn which trees are missing).\n\n Will merge to 'master'.\n\n\n* jt/pretend-object-never-come-from-elsewhere (2020-07-21) 1 commit\n  (merged to 'next' on 2020-08-03 at 36cd23aae5)\n + sha1-file: make pretend_object_file() not prefetch\n\n Originally merged to 'next' on 2020-08-01\n\n The pretend-object mechanism checks if the given object already\n exists in the object store before deciding to keep the data\n in-core, but the check would have triggered lazy fetching of such\n an object from a promissor remote.\n\n Will merge to 'master'.\n\n\n* bc/sha-256-part-3 (2020-07-30) 39 commits\n - t: remove test_oid_init in tests\n - docs: add documentation for extensions.objectFormat\n - ci: run tests with SHA-256\n - t: make SHA1 prerequisite depend on default hash\n - t: allow testing different hash algorithms via environment\n - t: add test_oid option to select hash algorithm\n - repository: enable SHA-256 support by default\n - setup: add support for reading extensions.objectformat\n - bundle: add new version for use with SHA-256\n - builtin/verify-pack: implement an --object-format option\n - http-fetch: set up git directory before parsing pack hashes\n - t0410: mark test with SHA1 prerequisite\n - t5308: make test work with SHA-256\n - t9700: make hash size independent\n - t9500: ensure that algorithm info is preserved in config\n - t9350: make hash size independent\n - t9301: make hash size independent\n - t9300: use $ZERO_OID instead of hard-coded object ID\n - t9300: abstract away SHA-1-specific constants\n - t8011: make hash size independent\n - t8003: make hash size independent\n - t8002: make hash size independent\n - t7508: use $ZERO_OID instead of hard-coded constant\n - t7506: avoid checking for SHA-1-specific constants\n - t7405: make hash size independent\n - t7400: make hash size independent\n - t7102: abstract away SHA-1-specific constants\n - t7201: abstract away SHA-1-specific constants\n - t7063: make hash size independent\n - t7003: compute appropriate length constant\n - t6501: avoid hard-coded objects\n - t6500: specify test values for SHA-256\n - t6301: make hash size independent\n - t6101: make hash size independent\n - t6100: make hash size independent\n - t3404: prepare 'short SHA-1 collision' tests for SHA-256\n - t3305: make hash agnostic\n - t1001: use $ZERO_OID\n - t: make test-bloom initialize repository\n\n The final leg of SHA-256 transition.\n\n Will merge to 'next'.\n\n\n* mp/complete-show-color-moved (2020-07-15) 1 commit\n  (merged to 'next' on 2020-08-03 at c90fea8e5e)\n + completion: add show --color-moved[-ws]\n\n Originally merged to 'next' on 2020-08-01\n\n Command line completion (in contrib/) update.\n\n Will merge to 'master'.\n A follow-up patch to reduce duplication may be warranted.\n\n\n* hn/reftable-prep-part-2 (2020-07-27) 3 commits\n - Make HEAD a PSEUDOREF rather than PER_WORKTREE.\n - Modify pseudo refs through ref backend storage\n - t1400: use git rev-parse for testing PSEUDOREF existence\n\n Further preliminary change to refs API.\n\n\n* ds/maintenance (2020-07-30) 20 commits\n - maintenance: add trace2 regions for task execution\n - midx: use start_delayed_progress()\n - maintenance: add incremental-repack auto condition\n - maintenance: create auto condition for loose-objects\n - maintenance: add auto condition for commit-graph task\n - maintenance: use pointers to check --auto\n - maintenance: create maintenance.<task>.enabled config\n - maintenance: auto-size incremental-repack batch\n - maintenance: add incremental-repack task\n - midx: enable core.multiPackIndex by default\n - maintenance: add loose-objects task\n - maintenance: add prefetch task\n - fetch: optionally allow disabling FETCH_HEAD update\n - maintenance: take a lock on the objects directory\n - maintenance: add --task option\n - maintenance: add commit-graph task\n - maintenance: initialize task array\n - maintenance: replace run_auto_gc()\n - maintenance: add --quiet option\n - maintenance: create basic maintenance runner\n (this branch uses jk/strvec.)\n\n A \"git gc\"'s big brother has been introduced to take care of more\n repository maintenance tasks, not limited to the object database\n cleaning.\n\n\n* ls/mergetool-meld-auto-merge (2020-07-12) 2 commits\n - SQUASH???\n - Support auto-merge for meld to follow the vim-diff behavior\n\n The 'meld' backend of the \"git mergetool\" learned to give the\n underlying 'meld' the '--auto-merge' option, which would help\n reduce the amount of text that requires manual merging.\n\n Expecting a reroll.\n\n\n* tb/upload-pack-filters (2020-08-03) 3 commits\n - upload-pack.c: introduce 'uploadpackfilter.tree.maxDepth'\n - upload-pack.c: allow banning certain object filter(s)\n - list_objects_filter_options: introduce 'list_object_filter_config_name'\n\n The component to respond to \"git fetch\" request is made more\n configurable to selectively allow or reject object filtering\n specification used for partial cloning.\n\n Will merge to 'next'.\n\n\n* mt/hash-to-hex-thread-safety (2020-06-26) 2 commits\n - hex: make hash_to_hex_algop() and friends thread-safe\n - compat/win32/pthread: add pthread_once()\n\n hash_to_hex() used a set of rotating static buffers, which was not\n safe to use in a threaded environment.  This has been made safer by\n using thread-local storage.\n\n Expecting a reroll.\n cf. <CAHd-oW6A2aBHg80R9kyifvF7thwzam5EYYoN9d2TaBcHJrcKWw@mail.gmail.com>\n\n\n* ss/cmake-build (2020-06-26) 8 commits\n  (merged to 'next' on 2020-08-03 at a0d70165c1)\n + ci: modification of main.yml to use cmake for vs-build job\n + cmake: support for building git on windows with msvc and clang.\n + cmake: support for building git on windows with mingw\n + cmake: support for testing git when building out of the source tree\n + cmake: support for testing git with ctest\n + cmake: installation support for git\n + cmake: generate the shell/perl/python scripts and templates, translations\n + Introduce CMake support for configuring Git\n\n Originally merged to 'next' on 2020-08-01\n\n CMake support to build with MSVC for Windows bypassing the Makefile.\n\n Will merge to 'master'.\n cf. https://github.com/git/git/runs/892824895\n\n\n* es/config-hooks (2020-07-30) 6 commits\n - hook: add 'run' subcommand\n - parse-options: parse into argv_array\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 The \"hooks defined in config\" topic.\n\n\n* pw/rebase-i-more-options (2020-07-16) 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 Waiting for a (hopefully final) review.\n\n\n* mt/grep-sparse-checkout (2020-06-12) 6 commits\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: facilitate addition of new cli options\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 Review needed on 4/6; otherwise looking sane.\n cf. <CABPp-BGdEyEeajYZj_rdxp=MyEQdszuyjVTax=hhYj3fOtRQUQ@mail.gmail.com>\n\n--------------------------------------------------\n[Discarded]\n\n* jk/fast-export-anonym (2020-06-22) 4 commits\n  (merged to 'next' on 2020-06-22 at b517b2f707)\n + fast-export: allow dumping the path mapping\n + fast-export: refactor path printing to not rely on stdout\n + fast-export: anonymize \"master\" refname\n + fast-export: allow dumping the refname mapping\n\n The way refnames are anonymized has been updated and a way to help\n debugging using the anonymized output hsa been added.\n\n Superseded by 'jk/fast-export-anonym-alt'.\n\n\n* jk/t6000-timestamp-fix (2020-07-07) 1 commit\n  (merged to 'next' on 2020-07-09 at 633bcd552f)\n + t6000: use test_tick consistently\n\n Test update.\n\n Now it is part of jk/tests-timestamp-fix with a larger scope.\n\n\n* jc/no-update-fetch-head (2020-07-29) 1 commit\n . fetch: optionally allow disabling FETCH_HEAD update\n\n \"git fetch\" learned the \"--[no-]write-fetch-head\" option to\n optionally stop describing what was fetched in FETCH_HEAD.\n\n Now it is part of ds/maintenance topic.\n"},{"id":"402828","messageId":"20200804185057.GA1400256@coredump.intra.peff.net","threadId":"53978","inReplyTo":"xmqq8sevt1lf.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-04T18:50:57Z","receivedAt":"2020-08-04T18:51:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 03, 2020 at 10:35:40PM -0700, Junio C Hamano wrote:\n\n> * ss/cmake-build (2020-06-26) 8 commits\n>   (merged to 'next' on 2020-08-03 at a0d70165c1)\n>  + ci: modification of main.yml to use cmake for vs-build job\n>  + cmake: support for building git on windows with msvc and clang.\n>  + cmake: support for building git on windows with mingw\n>  + cmake: support for testing git when building out of the source tree\n>  + cmake: support for testing git with ctest\n>  + cmake: installation support for git\n>  + cmake: generate the shell/perl/python scripts and templates, translations\n>  + Introduce CMake support for configuring Git\n> \n>  Originally merged to 'next' on 2020-08-01\n> \n>  CMake support to build with MSVC for Windows bypassing the Makefile.\n> \n>  Will merge to 'master'.\n>  cf. https://github.com/git/git/runs/892824895\n\nI ran into issues with this, as I have several in-progress topics (not\nyet sent to the list) that touch our Makefile, and they needed updates\nto the cmake file (because it reproduces a lot of the lists and logic\nfrom the Makefile).\n\nThe original philosophy behind putting it in contrib is that most people\nwouldn't have to care, and folks interested in cmake would be\nresponsible for keeping it up to date. But the top patch makes it hard\nto ignore, because the vs-build CI job will fail.\n\nI'm not sure of the right path forward. I was definitely unenthused to\nbe dealing with cmake, and the problem came up as soon as the series hit\nnext.\n\nOn the other hand, it was only 2 out of my 47 topics that triggered\nproblems. I'd guess that's representative of how often this will come\nup. And the vsbuild tests have to use _something_, so we may not be\nimmune to this problem regardless of the solution (though I never had to\ntouch the vcxproj files before). Part of me wants to just ignore vsbuild\ntest results completely, but it has provided value in the past (for\nactual code changes with portability issues).\n\nSo I dunno. I'm not really asking for or recommending any specific\naction, but just raising the data point.\n\n-Peff\n"},{"id":"402829","messageId":"xmqqr1sms0f0.fsf@gitster.c.googlers.com","threadId":"53978","inReplyTo":"20200804185057.GA1400256@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-04T18:58:43Z","receivedAt":"2020-08-04T18:58:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Mon, Aug 03, 2020 at 10:35:40PM -0700, Junio C Hamano wrote:\n>\n>> * ss/cmake-build (2020-06-26) 8 commits\n>>   (merged to 'next' on 2020-08-03 at a0d70165c1)\n>>  + ci: modification of main.yml to use cmake for vs-build job\n>>  + cmake: support for building git on windows with msvc and clang.\n>>  + cmake: support for building git on windows with mingw\n>>  + cmake: support for testing git when building out of the source tree\n>>  + cmake: support for testing git with ctest\n>>  + cmake: installation support for git\n>>  + cmake: generate the shell/perl/python scripts and templates, translations\n>>  + Introduce CMake support for configuring Git\n>> \n>>  Originally merged to 'next' on 2020-08-01\n>> \n>>  CMake support to build with MSVC for Windows bypassing the Makefile.\n>> \n>>  Will merge to 'master'.\n>>  cf. https://github.com/git/git/runs/892824895\n>\n> I ran into issues with this, as I have several in-progress topics (not\n> yet sent to the list) that touch our Makefile, and they needed updates\n> to the cmake file (because it reproduces a lot of the lists and logic\n> from the Makefile).\n>\n> The original philosophy behind putting it in contrib is that most people\n> wouldn't have to care, and folks interested in cmake would be\n> responsible for keeping it up to date. But the top patch makes it hard\n> to ignore, because the vs-build CI job will fail.\n>\n> I'm not sure of the right path forward. I was definitely unenthused to\n> be dealing with cmake, and the problem came up as soon as the series hit\n> next.\n\nMy hope is that if we let vs-build broken long enough, those who\nwant to see cmake to graduate would fix it.  We can always threaten\nthe topic to be discarded out of 'next' after the next release if it\nhasn't been fixed ;-)\n"},{"id":"402830","messageId":"20200804192053.GA1400936@coredump.intra.peff.net","threadId":"53978","inReplyTo":"xmqqr1sms0f0.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-04T19:20:53Z","receivedAt":"2020-08-04T19:20:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 04, 2020 at 11:58:43AM -0700, Junio C Hamano wrote:\n\n> > I ran into issues with this, as I have several in-progress topics (not\n> > yet sent to the list) that touch our Makefile, and they needed updates\n> > to the cmake file (because it reproduces a lot of the lists and logic\n> > from the Makefile).\n> >\n> > The original philosophy behind putting it in contrib is that most people\n> > wouldn't have to care, and folks interested in cmake would be\n> > responsible for keeping it up to date. But the top patch makes it hard\n> > to ignore, because the vs-build CI job will fail.\n> >\n> > I'm not sure of the right path forward. I was definitely unenthused to\n> > be dealing with cmake, and the problem came up as soon as the series hit\n> > next.\n> \n> My hope is that if we let vs-build broken long enough, those who\n> want to see cmake to graduate would fix it.  We can always threaten\n> the topic to be discarded out of 'next' after the next release if it\n> hasn't been fixed ;-)\n\nThat was my philosophy, too, but it's annoying in the meantime as I get\na notification for \"your build is broken\" every time I run CI. So it\nbecomes a game of chicken over who gets annoyed first. ;)\n\n-Peff\n"},{"id":"403022","messageId":"CANYiYbFjYAtrfdvPKKqveF8ADddhLG=9G9YSgJx5W_e2rxXUrg@mail.gmail.com","threadId":"53978","inReplyTo":"xmqq8sevt1lf.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Jiang Xin","fromEmail":"worldhello.net@gmail.com","sentAt":"2020-08-06T03:25:31Z","receivedAt":"2020-08-06T03:25:47Z","isPatch":false,"sender":{"key":"worldhello.net@gmail.com","avatar":"https://avatars.githubusercontent.com/u/183860?v=4"},"body":"Junio C Hamano <gitster@pobox.com> 于2020年8月4日周二 下午1:37写道：\n>\n> --------------------------------------------------\n> [Stalled]\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>  Ejected out of 'seen'; somehow its tests seem to break with clang\n>  cf. https://travis-ci.org/github/git/git/builds/713443572\n\nWill check the build log.\n\nBTW, I want to extend the syntax of the config variable\n\"receive.procReceiveRef\" like this:\n\n    git config receive.procReceiveRef \"kind:new,remove\"\n\nSo \"receive-pack\" can pass commands for creating or removing\ntags/branches to \"proc-receive\" to create pull request for these\noperations.\n\n--\nJiang Xin\n"},{"id":"403449","messageId":"nycvar.QRO.7.76.6.2008121516560.50@tvgsbejvaqbjf.bet","threadId":"53978","inReplyTo":"20200804192053.GA1400936@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-08-12T13:35:06Z","receivedAt":"2020-08-12T13:35:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Tue, 4 Aug 2020, Jeff King wrote:\n\n> On Tue, Aug 04, 2020 at 11:58:43AM -0700, Junio C Hamano wrote:\n>\n> > > I ran into issues with this, as I have several in-progress topics (not\n> > > yet sent to the list) that touch our Makefile, and they needed updates\n> > > to the cmake file (because it reproduces a lot of the lists and logic\n> > > from the Makefile).\n> > >\n> > > The original philosophy behind putting it in contrib is that most people\n> > > wouldn't have to care, and folks interested in cmake would be\n> > > responsible for keeping it up to date. But the top patch makes it hard\n> > > to ignore, because the vs-build CI job will fail.\n> > >\n> > > I'm not sure of the right path forward. I was definitely unenthused to\n> > > be dealing with cmake, and the problem came up as soon as the series hit\n> > > next.\n> >\n> > My hope is that if we let vs-build broken long enough, those who\n> > want to see cmake to graduate would fix it.  We can always threaten\n> > the topic to be discarded out of 'next' after the next release if it\n> > hasn't been fixed ;-)\n>\n> That was my philosophy, too, but it's annoying in the meantime as I get\n> a notification for \"your build is broken\" every time I run CI. So it\n> becomes a game of chicken over who gets annoyed first. ;)\n\nI am a bit sad to read all this, as I thought that we had reached\nconsensus that the `Makefile` _is_ the source of truth.\n\nBut then, most of the source files that need to be compiled _are_ parsed\nfrom the Makefile.\n\nSo I wonder what problems you ran into; Maybe we can come up with a\nstrategy how to preempt future instances of the same nature?\n\nCiao,\nDscho\n"},{"id":"403456","messageId":"20200812141958.GA32453@coredump.intra.peff.net","threadId":"53978","inReplyTo":"nycvar.QRO.7.76.6.2008121516560.50@tvgsbejvaqbjf.bet","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-12T14:19:58Z","receivedAt":"2020-08-12T14:20:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 12, 2020 at 03:35:06PM +0200, Johannes Schindelin wrote:\n\n> > That was my philosophy, too, but it's annoying in the meantime as I get\n> > a notification for \"your build is broken\" every time I run CI. So it\n> > becomes a game of chicken over who gets annoyed first. ;)\n> \n> I am a bit sad to read all this, as I thought that we had reached\n> consensus that the `Makefile` _is_ the source of truth.\n> \n> But then, most of the source files that need to be compiled _are_ parsed\n> from the Makefile.\n> \n> So I wonder what problems you ran into; Maybe we can come up with a\n> strategy how to preempt future instances of the same nature?\n\nThere are definitely a lot of lists that are copied from the Makefile\ninto CMakeLists. For some concrete data, here are the patches I needed\nfor two of my topics.\n\nThis first one is for a topic that remotes git-remote-testsvn and\nassociated code.\n\n---\n contrib/buildsystems/CMakeLists.txt | 26 +++++---------------------\n 1 file changed, 5 insertions(+), 21 deletions(-)\n\ndiff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt\nindex 4be61247e5..bdd3121a7c 100644\n--- a/contrib/buildsystems/CMakeLists.txt\n+++ b/contrib/buildsystems/CMakeLists.txt\n@@ -502,7 +502,7 @@ unset(CMAKE_REQUIRED_INCLUDES)\n #programs\n set(PROGRAMS_BUILT\n \tgit git-bugreport git-daemon git-fast-import git-http-backend git-sh-i18n--envsubst\n-\tgit-shell git-remote-testsvn)\n+\tgit-shell)\n \n if(NOT CURL_FOUND)\n \tlist(APPEND excluded_progs git-http-fetch git-http-push)\n@@ -568,12 +568,6 @@ parse_makefile_for_sources(libxdiff_SOURCES \"XDIFF_OBJS\")\n list(TRANSFORM libxdiff_SOURCES PREPEND \"${CMAKE_SOURCE_DIR}/\")\n add_library(xdiff STATIC ${libxdiff_SOURCES})\n \n-#libvcs-svn\n-parse_makefile_for_sources(libvcs-svn_SOURCES \"VCSSVN_OBJS\")\n-\n-list(TRANSFORM libvcs-svn_SOURCES PREPEND \"${CMAKE_SOURCE_DIR}/\")\n-add_library(vcs-svn STATIC ${libvcs-svn_SOURCES})\n-\n if(WIN32)\n \tif(NOT MSVC)#use windres when compiling with gcc and clang\n \t\tadd_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/git.res\n@@ -660,9 +654,6 @@ if(CURL_FOUND)\n \tendif()\n endif()\n \n-add_executable(git-remote-testsvn ${CMAKE_SOURCE_DIR}/remote-testsvn.c)\n-target_link_libraries(git-remote-testsvn common-main vcs-svn)\n-\n set(git_builtin_extra\n \tcherry cherry-pick format-patch fsck-objects\n \tinit merge-subtree restore show\n@@ -838,26 +829,20 @@ if(BUILD_TESTING)\n add_executable(test-fake-ssh ${CMAKE_SOURCE_DIR}/t/helper/test-fake-ssh.c)\n target_link_libraries(test-fake-ssh common-main)\n \n-add_executable(test-line-buffer ${CMAKE_SOURCE_DIR}/t/helper/test-line-buffer.c)\n-target_link_libraries(test-line-buffer common-main vcs-svn)\n-\n-add_executable(test-svn-fe ${CMAKE_SOURCE_DIR}/t/helper/test-svn-fe.c)\n-target_link_libraries(test-svn-fe common-main vcs-svn)\n-\n #test-tool\n parse_makefile_for_sources(test-tool_SOURCES \"TEST_BUILTINS_OBJS\")\n \n list(TRANSFORM test-tool_SOURCES PREPEND \"${CMAKE_SOURCE_DIR}/t/helper/\")\n add_executable(test-tool ${CMAKE_SOURCE_DIR}/t/helper/test-tool.c ${test-tool_SOURCES})\n target_link_libraries(test-tool common-main)\n \n-set_target_properties(test-fake-ssh test-line-buffer test-svn-fe test-tool\n+set_target_properties(test-fake-ssh test-tool\n \t\t\tPROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/t/helper)\n \n if(MSVC)\n-\tset_target_properties(test-fake-ssh test-line-buffer test-svn-fe test-tool\n+\tset_target_properties(test-fake-ssh test-tool\n \t\t\t\tPROPERTIES RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}/t/helper)\n-\tset_target_properties(test-fake-ssh test-line-buffer test-svn-fe test-tool\n+\tset_target_properties(test-fake-ssh test-tool\n \t\t\t\tPROPERTIES RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}/t/helper)\n endif()\n \n@@ -866,7 +851,7 @@ set(wrapper_scripts\n \tgit git-upload-pack git-receive-pack git-upload-archive git-shell git-remote-ext)\n \n set(wrapper_test_scripts\n-\ttest-fake-ssh test-line-buffer test-svn-fe test-tool)\n+\ttest-fake-ssh test-tool)\n \n \n foreach(script ${wrapper_scripts})\n@@ -967,7 +952,6 @@ if(NOT ${CMAKE_BINARY_DIR}/CMakeCache.txt STREQUAL ${CACHE_PATH})\n \tfile(COPY ${CMAKE_SOURCE_DIR}/mergetools/tkdiff DESTINATION ${CMAKE_BINARY_DIR}/mergetools/)\n \tfile(COPY ${CMAKE_SOURCE_DIR}/contrib/completion/git-prompt.sh DESTINATION ${CMAKE_BINARY_DIR}/contrib/completion/)\n \tfile(COPY ${CMAKE_SOURCE_DIR}/contrib/completion/git-completion.bash DESTINATION ${CMAKE_BINARY_DIR}/contrib/completion/)\n-\tfile(COPY ${CMAKE_SOURCE_DIR}/contrib/svn-fe/svnrdump_sim.py DESTINATION ${CMAKE_BINARY_DIR}/contrib/svn-fe/)\n endif()\n \n file(GLOB test_scipts \"${CMAKE_SOURCE_DIR}/t/t[0-9]*.sh\")\n\n\nIt's mostly removal, which is nice, but I think it gives a pretty clear\nexample of how often lists from Makefile are replicated (and often\nrepeated in several spots within CMakeLists). I suspect most of these\nlists could be pulled from the Makefile with a pre-processing step.\n\nThis second one is for a topic which moved some credential programs into\nbuiltins (since they link libgit.a and nothing else, there's no reason\nfor them to take up extra space on disk). Even if we read more lists\nfrom the Makefile, I think these hunks still would have needed to be\nmodified in CMakeLists because I changed the way they interact with\nNO_UNIX_SOCKETS (instead of not building credential-cache in that case,\nwe get a builtin that says \"sorry, this was built with\nNO_UNIX_SOCKETS\").\n\n---\n contrib/buildsystems/CMakeLists.txt | 20 +-------------------\n 1 file changed, 1 insertion(+), 19 deletions(-)\n\ndiff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt\nindex 47215df25b..4be61247e5 100644\n--- a/contrib/buildsystems/CMakeLists.txt\n+++ b/contrib/buildsystems/CMakeLists.txt\n@@ -501,15 +501,9 @@ unset(CMAKE_REQUIRED_INCLUDES)\n \n #programs\n set(PROGRAMS_BUILT\n-\tgit git-bugreport git-credential-store git-daemon git-fast-import git-http-backend git-sh-i18n--envsubst\n+\tgit git-bugreport git-daemon git-fast-import git-http-backend git-sh-i18n--envsubst\n \tgit-shell git-remote-testsvn)\n \n-if(NO_UNIX_SOCKETS)\n-\tlist(APPEND excluded_progs git-credential-cache git-credential-cache--daemon)\n-else()\n-\tlist(APPEND PROGRAMS_BUILT git-credential-cache git-credential-cache--daemon)\n-endif()\n-\n if(NOT CURL_FOUND)\n \tlist(APPEND excluded_progs git-http-fetch git-http-push)\n \tadd_compile_definitions(NO_CURL)\n@@ -633,9 +627,6 @@ target_link_libraries(git common-main)\n add_executable(git-bugreport ${CMAKE_SOURCE_DIR}/bugreport.c)\n target_link_libraries(git-bugreport common-main)\n \n-add_executable(git-credential-store ${CMAKE_SOURCE_DIR}/credential-store.c)\n-target_link_libraries(git-credential-store common-main)\n-\n add_executable(git-daemon ${CMAKE_SOURCE_DIR}/daemon.c)\n target_link_libraries(git-daemon common-main)\n \n@@ -672,15 +663,6 @@ endif()\n add_executable(git-remote-testsvn ${CMAKE_SOURCE_DIR}/remote-testsvn.c)\n target_link_libraries(git-remote-testsvn common-main vcs-svn)\n \n-if(NOT NO_UNIX_SOCKETS)\n-\tadd_executable(git-credential-cache ${CMAKE_SOURCE_DIR}/credential-cache.c)\n-\ttarget_link_libraries(git-credential-cache common-main)\n-\n-\tadd_executable(git-credential-cache--daemon ${CMAKE_SOURCE_DIR}/credential-cache--daemon.c)\n-\ttarget_link_libraries(git-credential-cache--daemon common-main)\n-endif()\n-\n-\n set(git_builtin_extra\n \tcherry cherry-pick format-patch fsck-objects\n \tinit merge-subtree restore show\n"},{"id":"403465","messageId":"CAKw82xxOZFcsMw47TSrD7-pXpqO7O0_m84o96iH6+ZVeN9j1uw@mail.gmail.com","threadId":"53978","inReplyTo":"20200812141958.GA32453@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Sibi Siddharthan","fromEmail":"sibisiv.siddharthan@gmail.com","sentAt":"2020-08-12T15:56:05Z","receivedAt":"2020-08-12T15:56:19Z","isPatch":false,"sender":{"key":"sibisiv.siddharthan@gmail.com","avatar":null},"body":"On Wed, Aug 12, 2020 at 7:50 PM Jeff King <peff@peff.net> wrote:\n>\n> On Wed, Aug 12, 2020 at 03:35:06PM +0200, Johannes Schindelin wrote:\n>\n> > > That was my philosophy, too, but it's annoying in the meantime as I get\n> > > a notification for \"your build is broken\" every time I run CI. So it\n> > > becomes a game of chicken over who gets annoyed first. ;)\n> >\n> > I am a bit sad to read all this, as I thought that we had reached\n> > consensus that the `Makefile` _is_ the source of truth.\n> >\n> > But then, most of the source files that need to be compiled _are_ parsed\n> > from the Makefile.\n> >\n> > So I wonder what problems you ran into; Maybe we can come up with a\n> > strategy how to preempt future instances of the same nature?\n>\n> There are definitely a lot of lists that are copied from the Makefile\n> into CMakeLists. For some concrete data, here are the patches I needed\n> for two of my topics.\n>\n> This first one is for a topic that remotes git-remote-testsvn and\n> associated code.\n\nThe reason for verbosely specifying the test programs (test-tool,\ntest-fake-ssh,etc)\nwas that test-tool required all the objects specified by\nTEST_BUILTIN_OBJS, whereas\ntest-fake-ssh requires only test-fake-ssh.o.\n\n> This second one is for a topic which moved some credential programs into\n> builtins (since they link libgit.a and nothing else, there's no reason\n> for them to take up extra space on disk). Even if we read more lists\n> from the Makefile, I think these hunks still would have needed to be\n> modified in CMakeLists because I changed the way they interact with\n> NO_UNIX_SOCKETS (instead of not building credential-cache in that case,\n> we get a builtin that says \"sorry, this was built with\n> NO_UNIX_SOCKETS\").\n>\n\nFor git programs like git-bugreport, git-imap-send which are specified\nwith PROGRAM_OBJS,\nwe don't know which of them require to be linked with libcurl or\nlibexpat. That was the reason\nthese programs were specified verbosely in the CMakeLists. In the\nfuture if a new program would be added\nwe need to add them to the PROGRAMS_BUILT list in CMakeLists as well\nand link it with its library dependencies.\n\nChanging the interaction with NO_UNIX_SOCKETS variable will require a\nchange in the CMakeLists file as well.\n\nThe CMake script was not intended to be a write once and forget\nsituation, it tries to pull from the Makefile as much\nas possible. A few changes are needed, which I intend to do.\n\nThank You,\nSibi Siddharthan\n"},{"id":"403466","messageId":"20200812160653.GA42443@coredump.intra.peff.net","threadId":"53978","inReplyTo":"CAKw82xxOZFcsMw47TSrD7-pXpqO7O0_m84o96iH6+ZVeN9j1uw@mail.gmail.com","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-12T16:06:53Z","receivedAt":"2020-08-12T16:06:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 12, 2020 at 09:26:05PM +0530, Sibi Siddharthan wrote:\n\n> The CMake script was not intended to be a write once and forget\n> situation, it tries to pull from the Makefile as much\n> as possible. A few changes are needed, which I intend to do.\n\nYeah, I know. My main beef was that because it fails CI, the urgency of\ndoing that fix gets pushed onto people working on their individual\ntopics (in fact there is nothing for you to fix yet because I haven't\neven sent these topics upstream). I don't know how to solve that without\nstopping its use in the vsbuild CI job, though. And clearly we need\n_something_ to generate the build data for that job. So this may be the\nlast bad thing.\n\nFrom my perspective as somebody who does not work on Windows, I wonder\nhow much value there is in running vsbuild _and_ Windows CI for average\ndevelopers. I have certainly gotten information from these jobs (e.g.,\nwhen introducing a portability problem, or missing a refactoring spot in\nWindows-only code). But I don't think I've ever gotten information from\nvsbuild that wasn't also in the regular windows build.\n\n-Peff\n"},{"id":"403499","messageId":"xmqqlfij63p8.fsf@gitster.c.googlers.com","threadId":"53978","inReplyTo":"20200812160653.GA42443@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-12T19:53:39Z","receivedAt":"2020-08-12T19:53:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Yeah, I know. My main beef was that because it fails CI, the urgency of\n> doing that fix gets pushed onto people working on their individual\n> topics (in fact there is nothing for you to fix yet because I haven't\n> even sent these topics upstream). I don't know how to solve that without\n> stopping its use in the vsbuild CI job, though.\n\nWhat I am not getting is in what way it blocks you (or others who do\nnot deeply care about Windows) to leave vsbuild CI job broken.  Do\nyou have some automation that is gated by all the CI jobs to pass,\nor do you just dislike failing CI jobs out of principle?\n\nI pretty much got used to seeing occasional failures and learned to\nignore it (e.g. https://travis-ci.org/github/git/git/jobs/716661598\nthat ends with\n\n    Makefile:2467: *** unterminated variable reference.  Stop.\n    make: *** Waiting for unfinished jobs....\n\n).\n\n"},{"id":"403502","messageId":"20200812201130.GB1340519@coredump.intra.peff.net","threadId":"53978","inReplyTo":"xmqqlfij63p8.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-12T20:11:30Z","receivedAt":"2020-08-12T20:11:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 12, 2020 at 12:53:39PM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > Yeah, I know. My main beef was that because it fails CI, the urgency of\n> > doing that fix gets pushed onto people working on their individual\n> > topics (in fact there is nothing for you to fix yet because I haven't\n> > even sent these topics upstream). I don't know how to solve that without\n> > stopping its use in the vsbuild CI job, though.\n> \n> What I am not getting is in what way it blocks you (or others who do\n> not deeply care about Windows) to leave vsbuild CI job broken.  Do\n> you have some automation that is gated by all the CI jobs to pass,\n> or do you just dislike failing CI jobs out of principle?\n\nIt's two things.\n\nThe first is \"out of principle\". If the vs-build job always fails, then\nI'll stop looking at it. So I'd never even see if it fails for a\nlegitimately interesting reason. And now there's no value in running it\nat all.\n\nThe second thing is annoyance. I get an email that says \"hey, your CI\njob failed\". And then I think \"oh no, I should figure out what it is\".\nAnd then I spend 10 minutes investigating only to find out that no, it's\nnot something I care about.\n\nIf the vs-build job always failed I could write it off in less time than\n10 minutes. But it's still not nothing, because the email still grabs my\nattention, and then I have to manually figure out that it was indeed\nvs-build and only vs-build which failed (which is not helped by the mail\nfrom GitHub consisting of 25 lines listing the succeeded jobs). Getting\nthat once a day isn't world-ending, but it is annoying (and I do get it\nonce a day because I do my own daily integration run, which is what I\npush to CI).\n\nSo rather than deal with that, I'd probably add more bits to our\nci/config to allow myself to just disable that job. For now I'm letting\nit run, though. I've fixed my two topics, and I'm curious to see if it\ncomes up again, and if so how long it takes.\n\n-Peff\n"},{"id":"403641","messageId":"nycvar.QRO.7.76.6.2008141352430.54@tvgsbejvaqbjf.bet","threadId":"53978","inReplyTo":"20200812160653.GA42443@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-08-14T12:08:28Z","receivedAt":"2020-08-14T12:08:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Wed, 12 Aug 2020, Jeff King wrote:\n\n> From my perspective as somebody who does not work on Windows, I wonder\n> how much value there is in running vsbuild _and_ Windows CI for average\n> developers. I have certainly gotten information from these jobs (e.g.,\n> when introducing a portability problem, or missing a refactoring spot in\n> Windows-only code). But I don't think I've ever gotten information from\n> vsbuild that wasn't also in the regular windows build.\n\nThere have not been a _ton_ of these instances, but there have been a\ncouple:\n\n2049b8dc65e (diffcore_rename(): use a stable sort, 2019-09-30)\n\n\tHere, MSVC pointed out that `qsort()` does not need to be stable,\n\tyet our test suite claimed that we expect it to be.\n\n116d1fa6c69 (vreportf(): avoid relying on stdio buffering, 2019-10-30)\n\n\tMSVC's code demonstrated that `fprintf()` prints out messages\n\tcharacter by character.\n\nc097b95a260 (msvc: avoid using minus operator on unsigned types, 2019-10-04)\n\n\tWe relied on some iffy behavior of GNU C which allows negating\n\tunsigned values (which cannot work if the high bit is set\n\talready).\n\ndbcd970c27b (push: do not pretend to return `int` from\n\t\t`die_push_simple()`, 2019-09-30)\n\n\tA non-void return type in a noreturn function is bogus.\n\nfdda1ac62d7 (t0001 (mingw): do not expect a specific order of\n\t\tstdout/stderr, 2019-06-19)\n\n\tA test that might even have been flaky on Linux failed frequently\n\tdue to an incorrect assumption whether `stdout` would be flushed\n\tbefore `stderr`.\n\nI cannot find any more instances, so yes, I agree that the\n`vs-build`/`vs-test` jobs might not be _all_ that necessary. So maybe we\nshould do something like this?\n\n-- snipsnap --\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 30425404eb3..2549fff8edd 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -122,7 +122,7 @@ jobs:\n         path: ${{env.FAILED_TEST_ARTIFACTS}}\n   vs-build:\n     needs: ci-config\n-    if: needs.ci-config.outputs.enabled == 'yes'\n+    if: (github.repository == 'git/git' || github.repository == 'gitgitgadget/git') && needs.ci-config.outputs.enabled == 'yes'\n     env:\n       MSYSTEM: MINGW64\n       NO_PERL: 1\n\n"},{"id":"403657","messageId":"20200814124011.GA4104592@coredump.intra.peff.net","threadId":"53978","inReplyTo":"nycvar.QRO.7.76.6.2008141352430.54@tvgsbejvaqbjf.bet","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-14T12:40:11Z","receivedAt":"2020-08-14T12:40:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 14, 2020 at 02:08:28PM +0200, Johannes Schindelin wrote:\n\n> On Wed, 12 Aug 2020, Jeff King wrote:\n> \n> > From my perspective as somebody who does not work on Windows, I wonder\n> > how much value there is in running vsbuild _and_ Windows CI for average\n> > developers. I have certainly gotten information from these jobs (e.g.,\n> > when introducing a portability problem, or missing a refactoring spot in\n> > Windows-only code). But I don't think I've ever gotten information from\n> > vsbuild that wasn't also in the regular windows build.\n> \n> There have not been a _ton_ of these instances, but there have been a\n> couple:\n\nThanks, that was exactly the kind of data I was interested in.\n\n> I cannot find any more instances, so yes, I agree that the\n> `vs-build`/`vs-test` jobs might not be _all_ that necessary. So maybe we\n> should do something like this?\n\nLet's leave it be for now. The topics I had to adjust due to cmake were\nones that I'd had sitting around for a while. So while I hit problems\nimmediately, now that the queue is drained it's not clear to me how\noften it will come up in practice.\n\n> -- snipsnap --\n> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> index 30425404eb3..2549fff8edd 100644\n> --- a/.github/workflows/main.yml\n> +++ b/.github/workflows/main.yml\n> @@ -122,7 +122,7 @@ jobs:\n>          path: ${{env.FAILED_TEST_ARTIFACTS}}\n>    vs-build:\n>      needs: ci-config\n> -    if: needs.ci-config.outputs.enabled == 'yes'\n> +    if: (github.repository == 'git/git' || github.repository == 'gitgitgadget/git') && needs.ci-config.outputs.enabled == 'yes'\n\nIf we do go this route, I'd consider defaulting it to on and just\nletting people disable it through needs.ci-config.outputs.vsbuild or\nsimilar.\n\n-Peff\n"},{"id":"403802","messageId":"nycvar.QRO.7.76.6.2008170640160.56@tvgsbejvaqbjf.bet","threadId":"53978","inReplyTo":"20200814124011.GA4104592@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-08-17T04:41:31Z","receivedAt":"2020-08-17T09:05:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Fri, 14 Aug 2020, Jeff King wrote:\n\n> On Fri, Aug 14, 2020 at 02:08:28PM +0200, Johannes Schindelin wrote:\n>\n> > On Wed, 12 Aug 2020, Jeff King wrote:\n> >\n> > > From my perspective as somebody who does not work on Windows, I wonder\n> > > how much value there is in running vsbuild _and_ Windows CI for average\n> > > developers. I have certainly gotten information from these jobs (e.g.,\n> > > when introducing a portability problem, or missing a refactoring spot in\n> > > Windows-only code). But I don't think I've ever gotten information from\n> > > vsbuild that wasn't also in the regular windows build.\n> >\n> > There have not been a _ton_ of these instances, but there have been a\n> > couple:\n>\n> Thanks, that was exactly the kind of data I was interested in.\n>\n> > I cannot find any more instances, so yes, I agree that the\n> > `vs-build`/`vs-test` jobs might not be _all_ that necessary. So maybe we\n> > should do something like this?\n>\n> Let's leave it be for now. The topics I had to adjust due to cmake were\n> ones that I'd had sitting around for a while. So while I hit problems\n> immediately, now that the queue is drained it's not clear to me how\n> often it will come up in practice.\n>\n> > -- snipsnap --\n> > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> > index 30425404eb3..2549fff8edd 100644\n> > --- a/.github/workflows/main.yml\n> > +++ b/.github/workflows/main.yml\n> > @@ -122,7 +122,7 @@ jobs:\n> >          path: ${{env.FAILED_TEST_ARTIFACTS}}\n> >    vs-build:\n> >      needs: ci-config\n> > -    if: needs.ci-config.outputs.enabled == 'yes'\n> > +    if: (github.repository == 'git/git' || github.repository == 'gitgitgadget/git') && needs.ci-config.outputs.enabled == 'yes'\n>\n> If we do go this route, I'd consider defaulting it to on and just\n> letting people disable it through needs.ci-config.outputs.vsbuild or\n> similar.\n\nOkay, let's leave it for now, and if there are more instances, go the\n`config-repo/ci/config/` route.\n\nCiao,\nDscho\n"},{"id":"403836","messageId":"xmqqmu2t2nsh.fsf@gitster.c.googlers.com","threadId":"53978","inReplyTo":"20200814124011.GA4104592@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-17T17:19:10Z","receivedAt":"2020-08-17T17:27:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> -    if: needs.ci-config.outputs.enabled == 'yes'\n>> +    if: (github.repository == 'git/git' || github.repository == 'gitgitgadget/git') && needs.ci-config.outputs.enabled == 'yes'\n>\n> If we do go this route, I'd consider defaulting it to on and just\n> letting people disable it through needs.ci-config.outputs.vsbuild or\n> similar.\n\nThat sounds like a good idea.  Special casing based on repositories\ndo not scale.\n"}]}