* What's cooking in git.git (Aug 2020, #01; Mon, 3) @ 2020-08-04 5:35 Junio C Hamano 2020-08-04 18:50 ` Jeff King 2020-08-06 3:25 ` Jiang Xin 0 siblings, 2 replies; 15+ messages in thread From: Junio C Hamano @ 2020-08-04 5:35 UTC (permalink / raw) To: git Here are the topics that have been cooking. Commits prefixed with '-' are only in 'seen' (formerly 'pu'---proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Some topics that have been cooking in 'next' during the previous cycle, in addition to some fixes to 2.28, have been merged to 'master', and the tip of 'next' has been rewound. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -------------------------------------------------- [New Topics] * en/eol-attrs-gotchas (2020-08-03) 4 commits - checkout: support renormalization with checkout -m <paths> - merge: make merge.renormalize work for all uses of merge machinery - t6038: remove problematic test - t6038: make tests fail for the right reason All "mergy" operations that internally use the merge-recursive machinery should honor the merge.renormalize configuration, but many of them didn't. Will merge to 'next'. * en/merge-recursive-comment-fixes (2020-08-02) 1 commit - merge-recursive: fix unclear and outright wrong comments Comment fix. Will merge to 'next'. * es/adjust-subtree-test-for-merge-msg-update (2020-08-03) 1 commit - Revert "contrib: subtree: adjust test to change in fmt-merge-msg" Adjust tests in contrib/ to the recent change to fmt-merge-msg. Will merge to 'next'. * es/worktree-cleanup (2020-07-31) 4 commits - worktree: retire special-case normalization of main worktree path - worktree: drop bogus and unnecessary path munging - worktree: drop unused code from get_linked_worktree() - worktree: drop pointless strbuf_release() Code cleanup around "worktree" API implementation. Will merge to 'next'. * es/worktree-doc-cleanups (2020-08-03) 5 commits - git-worktree.txt: link to man pages when citing other Git commands - git-worktree.txt: make start of new sentence more obvious - git-worktree.txt: fix minor grammatical issues - git-worktree.txt: consistently use term "working tree" - git-worktree.txt: employ fixed-width typeface consistently Doc cleanup around "worktree". Will merge to 'next'. * ma/t1450-quotefix (2020-08-01) 1 commit - t1450: fix quoting of NUL byte when corrupting pack Test fix. Will merge to 'next'. * ny/notes-doc-sample-update (2020-08-03) 1 commit - docs: improve the example that illustrates git-notes path names Doc updates. Will merge to 'next'. * pb/guide-docs (2020-08-02) 4 commits - SQUASH??? - git.txt: add list of guides - help: drop usage of 'common' and 'useful' for guides - command-list.txt: add missing 'gitcredentials' and 'gitremote-helpers' Update "git help guides" documentation organization. * rs/bisect-oid-to-hex-fix (2020-08-02) 1 commit - bisect: use oid_to_hex_r() instead of memcpy()+oid_to_hex() Code cleanup. Will merge to 'next'. * rs/more-buffered-io (2020-08-02) 3 commits - upload-pack: use buffered I/O to talk to rev-list - midx: use buffered I/O to talk to pack-objects - connected: use buffered I/O to talk to rev-list -------------------------------------------------- [Graduated to 'master'] * ar/help-guides-doc (2020-07-29) 1 commit (merged to 'next' on 2020-07-30 at e4b0370bfa) + git-help.txt: fix mentions of option --guides Doc update. * cc/pretty-contents-size (2020-07-31) 1 commit (merged to 'next' on 2020-07-31 at 0ad958f31d) + t6300: fix issues related to %(contents:size) Brown-paper-bag fix. * en/typofixes (2020-07-28) 2 commits (merged to 'next' on 2020-07-30 at 64776daa9a) + hashmap: fix typo in usage docs + Remove doubled words in various comments Typofixes. * hn/reftable (2020-07-31) 1 commit (merged to 'next' on 2020-07-31 at 9e34be957e) + refs: move the logic to add \t to reflog to the files backend Brown-paper-bag fix. * jb/doc-packfile-name (2020-07-22) 1 commit (merged to 'next' on 2020-07-30 at b46c3f6675) + pack-write/docs: update regarding pack naming Doc update. * jc/fmt-merge-msg-suppress-destination (2020-07-30) 2 commits (merged to 'next' on 2020-07-30 at c44f57f46d) + fmt-merge-msg: allow merge destination to be omitted again + Revert "fmt-merge-msg: stop treating `master` specially" "git merge" learned to selectively omit " into <branch>" at the end of the title of default merge message with merge.suppressDest configuration. * rs/grep-simpler-parse-object-or-die-call (2020-07-28) 1 commit (merged to 'next' on 2020-07-30 at 6d22dd3058) + grep: avoid using oid_to_hex() with parse_object_or_die() Code clean-up. * sg/ci-git-path-fix-with-pyenv (2020-07-23) 1 commit (merged to 'next' on 2020-07-30 at afe304633d) + ci: use absolute PYTHON_PATH in the Linux jobs CI fixup---tests of Python scripts didn't use the version of Git that is being tested. * sk/typofixes (2020-07-29) 1 commit (merged to 'next' on 2020-07-30 at c56d9e5313) + comment: fix spelling mistakes inside comments Typofixes. -------------------------------------------------- [Stalled] * jx/proc-receive-hook (2020-05-18) 11 commits . doc: add documentation for the proc-receive hook . transport: parse report options for tracking refs . t5411: test updates of remote-tracking branches . receive-pack: new config receive.procReceiveRefs . refs.c: refactor to reuse ref_is_hidden() . receive-pack: feed report options to post-receive . doc: add document for capability report-status-v2 . New capability "report-status-v2" for git-push . receive-pack: add new proc-receive hook . t5411: add basic test cases for proc-receive hook . transport: not report a non-head push as a branch "git receive-pack" that accepts requests by "git push" learned to outsource most of the ref updates to the new "proc-receive" hook. Ejected out of 'seen'; somehow its tests seem to break with clang cf. https://travis-ci.org/github/git/git/builds/713443572 * mf/submodule-summary-with-correct-repository (2020-06-24) 2 commits - submodule: use submodule repository when preparing summary - revision: use repository from rev_info when parsing commits "git diff/show" on a change that involves a submodule used to read the information on commits in the submodule from a wrong repository and gave a wrong information when the commit-graph is involved. Needs tests. * dr/push-remoteref-fix (2020-04-23) 1 commit - remote.c: fix handling of %(push:remoteref) The "%(push:remoteref)" placeholder in the "--format=" argument of "git format-patch" (and friends) only showed what got explicitly configured, not what ref at the receiving end would be updated when "git push" was used, as it ignored the default behaviour (e.g. update the same ref as the source). Expecting a reroll. cf. <20200416152145.wp2zeibxmuyas6y6@feanor> * mr/bisect-in-c-2 (2020-07-17) 14 commits . SQUASH??? do not add new users of git_path_bisect_head() . bisect--helper: retire `--bisect-autostart` subcommand . bisect--helper: retire `--write-terms` subcommand . bisect--helper: retire `--check-expected-revs` subcommand . bisect--helper: reimplement `bisect_state` & `bisect_head` shell functions in C . bisect--helper: retire `--next-all` subcommand . bisect--helper: retire `--bisect-clean-state` subcommand . bisect--helper: finish porting `bisect_start()` to C . bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C . bisect: call 'clear_commit_marks_all()' in 'bisect_next_all()' . bisect--helper: reimplement `bisect_autostart` shell function in C . bisect--helper: introduce new `write_in_file()` function . bisect--helper: use '-res' in 'cmd_bisect__helper' return . bisect--helper: BUG() in cmd_*() on invalid subcommand Rewrite of the remainder of "git bisect" script in C continues. Needs more work. Ejected out of 'seen'; al/bisect-first-parent topic has a bit of textual conflict with this topic. * mk/use-size-t-in-zlib (2018-10-15) 1 commit - zlib.c: use size_t for size The wrapper to call into zlib followed our long tradition to use "unsigned long" for sizes of regions in memory, which have been updated to use "size_t". -------------------------------------------------- [Cooking] * jk/log-fp-implies-m (2020-07-29) 7 commits (merged to 'next' on 2020-08-03 at 39fefa6b82) + doc/git-log: clarify handling of merge commit diffs + doc/git-log: move "-t" into diff-options list + doc/git-log: drop "-r" diff option + doc/git-log: move "Diff Formatting" from rev-list-options + log: enable "-m" automatically with "--first-parent" + revision: add "--no-diff-merges" option to counteract "-m" + log: drop "--cc implies -m" logic Originally merged to 'next' on 2020-08-01 "git log --first-parent -p" showed patches only for single-parent commits on the first-parent chain; the "--first-parent" option has been made to imply "-m". Use "--no-diff-merges" to restore the previous behaviour to omit patches for merge commits. Waiting for the discussion to settle. cf. <87lfivqvgf.fsf@osv.gnss.ru> If Sergey wants to send in --diff-merges=(none|<num>|c|cc|all) enhancement reasonably soon, I do not mind holding this off for a bit longer out of 'master'. * jk/strvec (2020-07-30) 11 commits - strvec: rename struct fields - strvec: drop argv_array compatibility layer - strvec: update documention to avoid argv_array - strvec: fix indentation in renamed calls - strvec: convert remaining callers away from argv_array name - strvec: convert more callers away from argv_array name - strvec: convert builtin/ callers away from argv_array name - quote: rename sq_dequote_to_argv_array to mention strvec - strvec: rename files from argv-array to strvec - argv-array: rename to strvec - argv-array: use size_t for count and alloc (this branch is used by ds/maintenance.) The argv_array API is useful for not just managing argv but any "vector" (NULL-terminated array) of strings, and has seen adoption to a certain degree. It has been renamed to "strvec" to reduce the barrier to adoption. Will merge to 'next'. * pd/mergetool-nvimdiff (2020-07-29) 2 commits - mergetools: add support for nvimdiff (neovim) family - mergetool--lib: improve support for vimdiff-style tool variants The existing backends for "git mergetool" based on variants of vim have been refactored and then support for "nvim" has been added. * al/bisect-first-parent (2020-07-29) 3 commits - bisect: combine args passed to find_bisection() - bisect: introduce first-parent flag - rev-list: allow bisect and first-parent flags "git bisect" learns the "--first-parent" option to find the first breakage along the first-parent chain. * dd/send-email-config (2020-07-23) 1 commit - git-send-email: die if sendmail.* config is set Stop when "sendmail.*" configuration variables are defined, which could be a mistaken attempt to define "sendemail.*" variables. * jt/pack-objects-prefetch-in-batch (2020-07-21) 2 commits (merged to 'next' on 2020-08-03 at 29424e614d) + pack-objects: prefetch objects to be packed + pack-objects: refactor to oid_object_info_extended Originally merged to 'next' on 2020-08-01 While packing many objects in a repository with a promissor remote, lazily fetching missing objects from the promissor remote one by one may be inefficient---the code now attempts to fetch all the missing objects in batch (obviously this won't work for a lazy clone that lazily fetches tree objects as you cannot even enumerate what blobs are missing until you learn which trees are missing). Will merge to 'master'. * jt/pretend-object-never-come-from-elsewhere (2020-07-21) 1 commit (merged to 'next' on 2020-08-03 at 36cd23aae5) + sha1-file: make pretend_object_file() not prefetch Originally merged to 'next' on 2020-08-01 The pretend-object mechanism checks if the given object already exists in the object store before deciding to keep the data in-core, but the check would have triggered lazy fetching of such an object from a promissor remote. Will merge to 'master'. * bc/sha-256-part-3 (2020-07-30) 39 commits - t: remove test_oid_init in tests - docs: add documentation for extensions.objectFormat - ci: run tests with SHA-256 - t: make SHA1 prerequisite depend on default hash - t: allow testing different hash algorithms via environment - t: add test_oid option to select hash algorithm - repository: enable SHA-256 support by default - setup: add support for reading extensions.objectformat - bundle: add new version for use with SHA-256 - builtin/verify-pack: implement an --object-format option - http-fetch: set up git directory before parsing pack hashes - t0410: mark test with SHA1 prerequisite - t5308: make test work with SHA-256 - t9700: make hash size independent - t9500: ensure that algorithm info is preserved in config - t9350: make hash size independent - t9301: make hash size independent - t9300: use $ZERO_OID instead of hard-coded object ID - t9300: abstract away SHA-1-specific constants - t8011: make hash size independent - t8003: make hash size independent - t8002: make hash size independent - t7508: use $ZERO_OID instead of hard-coded constant - t7506: avoid checking for SHA-1-specific constants - t7405: make hash size independent - t7400: make hash size independent - t7102: abstract away SHA-1-specific constants - t7201: abstract away SHA-1-specific constants - t7063: make hash size independent - t7003: compute appropriate length constant - t6501: avoid hard-coded objects - t6500: specify test values for SHA-256 - t6301: make hash size independent - t6101: make hash size independent - t6100: make hash size independent - t3404: prepare 'short SHA-1 collision' tests for SHA-256 - t3305: make hash agnostic - t1001: use $ZERO_OID - t: make test-bloom initialize repository The final leg of SHA-256 transition. Will merge to 'next'. * mp/complete-show-color-moved (2020-07-15) 1 commit (merged to 'next' on 2020-08-03 at c90fea8e5e) + completion: add show --color-moved[-ws] Originally merged to 'next' on 2020-08-01 Command line completion (in contrib/) update. Will merge to 'master'. A follow-up patch to reduce duplication may be warranted. * hn/reftable-prep-part-2 (2020-07-27) 3 commits - Make HEAD a PSEUDOREF rather than PER_WORKTREE. - Modify pseudo refs through ref backend storage - t1400: use git rev-parse for testing PSEUDOREF existence Further preliminary change to refs API. * ds/maintenance (2020-07-30) 20 commits - maintenance: add trace2 regions for task execution - midx: use start_delayed_progress() - maintenance: add incremental-repack auto condition - maintenance: create auto condition for loose-objects - maintenance: add auto condition for commit-graph task - maintenance: use pointers to check --auto - maintenance: create maintenance.<task>.enabled config - maintenance: auto-size incremental-repack batch - maintenance: add incremental-repack task - midx: enable core.multiPackIndex by default - maintenance: add loose-objects task - maintenance: add prefetch task - fetch: optionally allow disabling FETCH_HEAD update - maintenance: take a lock on the objects directory - maintenance: add --task option - maintenance: add commit-graph task - maintenance: initialize task array - maintenance: replace run_auto_gc() - maintenance: add --quiet option - maintenance: create basic maintenance runner (this branch uses jk/strvec.) A "git gc"'s big brother has been introduced to take care of more repository maintenance tasks, not limited to the object database cleaning. * ls/mergetool-meld-auto-merge (2020-07-12) 2 commits - SQUASH??? - Support auto-merge for meld to follow the vim-diff behavior The 'meld' backend of the "git mergetool" learned to give the underlying 'meld' the '--auto-merge' option, which would help reduce the amount of text that requires manual merging. Expecting a reroll. * tb/upload-pack-filters (2020-08-03) 3 commits - upload-pack.c: introduce 'uploadpackfilter.tree.maxDepth' - upload-pack.c: allow banning certain object filter(s) - list_objects_filter_options: introduce 'list_object_filter_config_name' The component to respond to "git fetch" request is made more configurable to selectively allow or reject object filtering specification used for partial cloning. Will merge to 'next'. * mt/hash-to-hex-thread-safety (2020-06-26) 2 commits - hex: make hash_to_hex_algop() and friends thread-safe - compat/win32/pthread: add pthread_once() hash_to_hex() used a set of rotating static buffers, which was not safe to use in a threaded environment. This has been made safer by using thread-local storage. Expecting a reroll. cf. <CAHd-oW6A2aBHg80R9kyifvF7thwzam5EYYoN9d2TaBcHJrcKWw@mail.gmail.com> * ss/cmake-build (2020-06-26) 8 commits (merged to 'next' on 2020-08-03 at a0d70165c1) + ci: modification of main.yml to use cmake for vs-build job + cmake: support for building git on windows with msvc and clang. + cmake: support for building git on windows with mingw + cmake: support for testing git when building out of the source tree + cmake: support for testing git with ctest + cmake: installation support for git + cmake: generate the shell/perl/python scripts and templates, translations + Introduce CMake support for configuring Git Originally merged to 'next' on 2020-08-01 CMake support to build with MSVC for Windows bypassing the Makefile. Will merge to 'master'. cf. https://github.com/git/git/runs/892824895 * es/config-hooks (2020-07-30) 6 commits - hook: add 'run' subcommand - parse-options: parse into argv_array - hook: add --porcelain to list command - hook: add list command - hook: scaffolding for git-hook subcommand - doc: propose hooks managed by the config The "hooks defined in config" topic. * pw/rebase-i-more-options (2020-07-16) 5 commits - rebase: add --reset-author-date - rebase -i: support --ignore-date - sequencer: rename amend_author to author_to_free - rebase -i: support --committer-date-is-author-date - rebase -i: add --ignore-whitespace flag "git rebase -i" learns a bit more options. Waiting for a (hopefully final) review. * mt/grep-sparse-checkout (2020-06-12) 6 commits - config: add setting to ignore sparsity patterns in some cmds - grep: honor sparse checkout patterns - config: correctly read worktree configs in submodules - t/helper/test-config: facilitate addition of new cli options - t/helper/test-config: return exit codes consistently - doc: grep: unify info on configuration variables "git grep" has been tweaked to be limited to the sparse checkout paths. Review needed on 4/6; otherwise looking sane. cf. <CABPp-BGdEyEeajYZj_rdxp=MyEQdszuyjVTax=hhYj3fOtRQUQ@mail.gmail.com> -------------------------------------------------- [Discarded] * jk/fast-export-anonym (2020-06-22) 4 commits (merged to 'next' on 2020-06-22 at b517b2f707) + fast-export: allow dumping the path mapping + fast-export: refactor path printing to not rely on stdout + fast-export: anonymize "master" refname + fast-export: allow dumping the refname mapping The way refnames are anonymized has been updated and a way to help debugging using the anonymized output hsa been added. Superseded by 'jk/fast-export-anonym-alt'. * jk/t6000-timestamp-fix (2020-07-07) 1 commit (merged to 'next' on 2020-07-09 at 633bcd552f) + t6000: use test_tick consistently Test update. Now it is part of jk/tests-timestamp-fix with a larger scope. * jc/no-update-fetch-head (2020-07-29) 1 commit . fetch: optionally allow disabling FETCH_HEAD update "git fetch" learned the "--[no-]write-fetch-head" option to optionally stop describing what was fetched in FETCH_HEAD. Now it is part of ds/maintenance topic. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-04 5:35 What's cooking in git.git (Aug 2020, #01; Mon, 3) Junio C Hamano @ 2020-08-04 18:50 ` Jeff King 2020-08-04 18:58 ` Junio C Hamano 2020-08-06 3:25 ` Jiang Xin 1 sibling, 1 reply; 15+ messages in thread From: Jeff King @ 2020-08-04 18:50 UTC (permalink / raw) To: Junio C Hamano; +Cc: Sibi Siddharthan, git On Mon, Aug 03, 2020 at 10:35:40PM -0700, Junio C Hamano wrote: > * ss/cmake-build (2020-06-26) 8 commits > (merged to 'next' on 2020-08-03 at a0d70165c1) > + ci: modification of main.yml to use cmake for vs-build job > + cmake: support for building git on windows with msvc and clang. > + cmake: support for building git on windows with mingw > + cmake: support for testing git when building out of the source tree > + cmake: support for testing git with ctest > + cmake: installation support for git > + cmake: generate the shell/perl/python scripts and templates, translations > + Introduce CMake support for configuring Git > > Originally merged to 'next' on 2020-08-01 > > CMake support to build with MSVC for Windows bypassing the Makefile. > > Will merge to 'master'. > cf. https://github.com/git/git/runs/892824895 I ran into issues with this, as I have several in-progress topics (not yet sent to the list) that touch our Makefile, and they needed updates to the cmake file (because it reproduces a lot of the lists and logic from the Makefile). The original philosophy behind putting it in contrib is that most people wouldn't have to care, and folks interested in cmake would be responsible for keeping it up to date. But the top patch makes it hard to ignore, because the vs-build CI job will fail. I'm not sure of the right path forward. I was definitely unenthused to be dealing with cmake, and the problem came up as soon as the series hit next. On the other hand, it was only 2 out of my 47 topics that triggered problems. I'd guess that's representative of how often this will come up. And the vsbuild tests have to use _something_, so we may not be immune to this problem regardless of the solution (though I never had to touch the vcxproj files before). Part of me wants to just ignore vsbuild test results completely, but it has provided value in the past (for actual code changes with portability issues). So I dunno. I'm not really asking for or recommending any specific action, but just raising the data point. -Peff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-04 18:50 ` Jeff King @ 2020-08-04 18:58 ` Junio C Hamano 2020-08-04 19:20 ` Jeff King 0 siblings, 1 reply; 15+ messages in thread From: Junio C Hamano @ 2020-08-04 18:58 UTC (permalink / raw) To: Jeff King; +Cc: Sibi Siddharthan, git Jeff King <peff@peff.net> writes: > On Mon, Aug 03, 2020 at 10:35:40PM -0700, Junio C Hamano wrote: > >> * ss/cmake-build (2020-06-26) 8 commits >> (merged to 'next' on 2020-08-03 at a0d70165c1) >> + ci: modification of main.yml to use cmake for vs-build job >> + cmake: support for building git on windows with msvc and clang. >> + cmake: support for building git on windows with mingw >> + cmake: support for testing git when building out of the source tree >> + cmake: support for testing git with ctest >> + cmake: installation support for git >> + cmake: generate the shell/perl/python scripts and templates, translations >> + Introduce CMake support for configuring Git >> >> Originally merged to 'next' on 2020-08-01 >> >> CMake support to build with MSVC for Windows bypassing the Makefile. >> >> Will merge to 'master'. >> cf. https://github.com/git/git/runs/892824895 > > I ran into issues with this, as I have several in-progress topics (not > yet sent to the list) that touch our Makefile, and they needed updates > to the cmake file (because it reproduces a lot of the lists and logic > from the Makefile). > > The original philosophy behind putting it in contrib is that most people > wouldn't have to care, and folks interested in cmake would be > responsible for keeping it up to date. But the top patch makes it hard > to ignore, because the vs-build CI job will fail. > > I'm not sure of the right path forward. I was definitely unenthused to > be dealing with cmake, and the problem came up as soon as the series hit > next. My hope is that if we let vs-build broken long enough, those who want to see cmake to graduate would fix it. We can always threaten the topic to be discarded out of 'next' after the next release if it hasn't been fixed ;-) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-04 18:58 ` Junio C Hamano @ 2020-08-04 19:20 ` Jeff King 2020-08-12 13:35 ` Johannes Schindelin 0 siblings, 1 reply; 15+ messages in thread From: Jeff King @ 2020-08-04 19:20 UTC (permalink / raw) To: Junio C Hamano; +Cc: Sibi Siddharthan, git On Tue, Aug 04, 2020 at 11:58:43AM -0700, Junio C Hamano wrote: > > I ran into issues with this, as I have several in-progress topics (not > > yet sent to the list) that touch our Makefile, and they needed updates > > to the cmake file (because it reproduces a lot of the lists and logic > > from the Makefile). > > > > The original philosophy behind putting it in contrib is that most people > > wouldn't have to care, and folks interested in cmake would be > > responsible for keeping it up to date. But the top patch makes it hard > > to ignore, because the vs-build CI job will fail. > > > > I'm not sure of the right path forward. I was definitely unenthused to > > be dealing with cmake, and the problem came up as soon as the series hit > > next. > > My hope is that if we let vs-build broken long enough, those who > want to see cmake to graduate would fix it. We can always threaten > the topic to be discarded out of 'next' after the next release if it > hasn't been fixed ;-) That was my philosophy, too, but it's annoying in the meantime as I get a notification for "your build is broken" every time I run CI. So it becomes a game of chicken over who gets annoyed first. ;) -Peff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-04 19:20 ` Jeff King @ 2020-08-12 13:35 ` Johannes Schindelin 2020-08-12 14:19 ` Jeff King 0 siblings, 1 reply; 15+ messages in thread From: Johannes Schindelin @ 2020-08-12 13:35 UTC (permalink / raw) To: Jeff King; +Cc: Junio C Hamano, Sibi Siddharthan, git Hi Peff, On Tue, 4 Aug 2020, Jeff King wrote: > On Tue, Aug 04, 2020 at 11:58:43AM -0700, Junio C Hamano wrote: > > > > I ran into issues with this, as I have several in-progress topics (not > > > yet sent to the list) that touch our Makefile, and they needed updates > > > to the cmake file (because it reproduces a lot of the lists and logic > > > from the Makefile). > > > > > > The original philosophy behind putting it in contrib is that most people > > > wouldn't have to care, and folks interested in cmake would be > > > responsible for keeping it up to date. But the top patch makes it hard > > > to ignore, because the vs-build CI job will fail. > > > > > > I'm not sure of the right path forward. I was definitely unenthused to > > > be dealing with cmake, and the problem came up as soon as the series hit > > > next. > > > > My hope is that if we let vs-build broken long enough, those who > > want to see cmake to graduate would fix it. We can always threaten > > the topic to be discarded out of 'next' after the next release if it > > hasn't been fixed ;-) > > That was my philosophy, too, but it's annoying in the meantime as I get > a notification for "your build is broken" every time I run CI. So it > becomes a game of chicken over who gets annoyed first. ;) I am a bit sad to read all this, as I thought that we had reached consensus that the `Makefile` _is_ the source of truth. But then, most of the source files that need to be compiled _are_ parsed from the Makefile. So I wonder what problems you ran into; Maybe we can come up with a strategy how to preempt future instances of the same nature? Ciao, Dscho ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-12 13:35 ` Johannes Schindelin @ 2020-08-12 14:19 ` Jeff King 2020-08-12 15:56 ` Sibi Siddharthan 0 siblings, 1 reply; 15+ messages in thread From: Jeff King @ 2020-08-12 14:19 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, Sibi Siddharthan, git On Wed, Aug 12, 2020 at 03:35:06PM +0200, Johannes Schindelin wrote: > > That was my philosophy, too, but it's annoying in the meantime as I get > > a notification for "your build is broken" every time I run CI. So it > > becomes a game of chicken over who gets annoyed first. ;) > > I am a bit sad to read all this, as I thought that we had reached > consensus that the `Makefile` _is_ the source of truth. > > But then, most of the source files that need to be compiled _are_ parsed > from the Makefile. > > So I wonder what problems you ran into; Maybe we can come up with a > strategy how to preempt future instances of the same nature? There are definitely a lot of lists that are copied from the Makefile into CMakeLists. For some concrete data, here are the patches I needed for two of my topics. This first one is for a topic that remotes git-remote-testsvn and associated code. --- contrib/buildsystems/CMakeLists.txt | 26 +++++--------------------- 1 file changed, 5 insertions(+), 21 deletions(-) diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt index 4be61247e5..bdd3121a7c 100644 --- a/contrib/buildsystems/CMakeLists.txt +++ b/contrib/buildsystems/CMakeLists.txt @@ -502,7 +502,7 @@ unset(CMAKE_REQUIRED_INCLUDES) #programs set(PROGRAMS_BUILT git git-bugreport git-daemon git-fast-import git-http-backend git-sh-i18n--envsubst - git-shell git-remote-testsvn) + git-shell) if(NOT CURL_FOUND) list(APPEND excluded_progs git-http-fetch git-http-push) @@ -568,12 +568,6 @@ parse_makefile_for_sources(libxdiff_SOURCES "XDIFF_OBJS") list(TRANSFORM libxdiff_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/") add_library(xdiff STATIC ${libxdiff_SOURCES}) -#libvcs-svn -parse_makefile_for_sources(libvcs-svn_SOURCES "VCSSVN_OBJS") - -list(TRANSFORM libvcs-svn_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/") -add_library(vcs-svn STATIC ${libvcs-svn_SOURCES}) - if(WIN32) if(NOT MSVC)#use windres when compiling with gcc and clang add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/git.res @@ -660,9 +654,6 @@ if(CURL_FOUND) endif() endif() -add_executable(git-remote-testsvn ${CMAKE_SOURCE_DIR}/remote-testsvn.c) -target_link_libraries(git-remote-testsvn common-main vcs-svn) - set(git_builtin_extra cherry cherry-pick format-patch fsck-objects init merge-subtree restore show @@ -838,26 +829,20 @@ if(BUILD_TESTING) add_executable(test-fake-ssh ${CMAKE_SOURCE_DIR}/t/helper/test-fake-ssh.c) target_link_libraries(test-fake-ssh common-main) -add_executable(test-line-buffer ${CMAKE_SOURCE_DIR}/t/helper/test-line-buffer.c) -target_link_libraries(test-line-buffer common-main vcs-svn) - -add_executable(test-svn-fe ${CMAKE_SOURCE_DIR}/t/helper/test-svn-fe.c) -target_link_libraries(test-svn-fe common-main vcs-svn) - #test-tool parse_makefile_for_sources(test-tool_SOURCES "TEST_BUILTINS_OBJS") list(TRANSFORM test-tool_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/t/helper/") add_executable(test-tool ${CMAKE_SOURCE_DIR}/t/helper/test-tool.c ${test-tool_SOURCES}) target_link_libraries(test-tool common-main) -set_target_properties(test-fake-ssh test-line-buffer test-svn-fe test-tool +set_target_properties(test-fake-ssh test-tool PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/t/helper) if(MSVC) - set_target_properties(test-fake-ssh test-line-buffer test-svn-fe test-tool + set_target_properties(test-fake-ssh test-tool PROPERTIES RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}/t/helper) - set_target_properties(test-fake-ssh test-line-buffer test-svn-fe test-tool + set_target_properties(test-fake-ssh test-tool PROPERTIES RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}/t/helper) endif() @@ -866,7 +851,7 @@ set(wrapper_scripts git git-upload-pack git-receive-pack git-upload-archive git-shell git-remote-ext) set(wrapper_test_scripts - test-fake-ssh test-line-buffer test-svn-fe test-tool) + test-fake-ssh test-tool) foreach(script ${wrapper_scripts}) @@ -967,7 +952,6 @@ if(NOT ${CMAKE_BINARY_DIR}/CMakeCache.txt STREQUAL ${CACHE_PATH}) file(COPY ${CMAKE_SOURCE_DIR}/mergetools/tkdiff DESTINATION ${CMAKE_BINARY_DIR}/mergetools/) file(COPY ${CMAKE_SOURCE_DIR}/contrib/completion/git-prompt.sh DESTINATION ${CMAKE_BINARY_DIR}/contrib/completion/) file(COPY ${CMAKE_SOURCE_DIR}/contrib/completion/git-completion.bash DESTINATION ${CMAKE_BINARY_DIR}/contrib/completion/) - file(COPY ${CMAKE_SOURCE_DIR}/contrib/svn-fe/svnrdump_sim.py DESTINATION ${CMAKE_BINARY_DIR}/contrib/svn-fe/) endif() file(GLOB test_scipts "${CMAKE_SOURCE_DIR}/t/t[0-9]*.sh") It's mostly removal, which is nice, but I think it gives a pretty clear example of how often lists from Makefile are replicated (and often repeated in several spots within CMakeLists). I suspect most of these lists could be pulled from the Makefile with a pre-processing step. This second one is for a topic which moved some credential programs into builtins (since they link libgit.a and nothing else, there's no reason for them to take up extra space on disk). Even if we read more lists from the Makefile, I think these hunks still would have needed to be modified in CMakeLists because I changed the way they interact with NO_UNIX_SOCKETS (instead of not building credential-cache in that case, we get a builtin that says "sorry, this was built with NO_UNIX_SOCKETS"). --- contrib/buildsystems/CMakeLists.txt | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt index 47215df25b..4be61247e5 100644 --- a/contrib/buildsystems/CMakeLists.txt +++ b/contrib/buildsystems/CMakeLists.txt @@ -501,15 +501,9 @@ unset(CMAKE_REQUIRED_INCLUDES) #programs set(PROGRAMS_BUILT - git git-bugreport git-credential-store git-daemon git-fast-import git-http-backend git-sh-i18n--envsubst + git git-bugreport git-daemon git-fast-import git-http-backend git-sh-i18n--envsubst git-shell git-remote-testsvn) -if(NO_UNIX_SOCKETS) - list(APPEND excluded_progs git-credential-cache git-credential-cache--daemon) -else() - list(APPEND PROGRAMS_BUILT git-credential-cache git-credential-cache--daemon) -endif() - if(NOT CURL_FOUND) list(APPEND excluded_progs git-http-fetch git-http-push) add_compile_definitions(NO_CURL) @@ -633,9 +627,6 @@ target_link_libraries(git common-main) add_executable(git-bugreport ${CMAKE_SOURCE_DIR}/bugreport.c) target_link_libraries(git-bugreport common-main) -add_executable(git-credential-store ${CMAKE_SOURCE_DIR}/credential-store.c) -target_link_libraries(git-credential-store common-main) - add_executable(git-daemon ${CMAKE_SOURCE_DIR}/daemon.c) target_link_libraries(git-daemon common-main) @@ -672,15 +663,6 @@ endif() add_executable(git-remote-testsvn ${CMAKE_SOURCE_DIR}/remote-testsvn.c) target_link_libraries(git-remote-testsvn common-main vcs-svn) -if(NOT NO_UNIX_SOCKETS) - add_executable(git-credential-cache ${CMAKE_SOURCE_DIR}/credential-cache.c) - target_link_libraries(git-credential-cache common-main) - - add_executable(git-credential-cache--daemon ${CMAKE_SOURCE_DIR}/credential-cache--daemon.c) - target_link_libraries(git-credential-cache--daemon common-main) -endif() - - set(git_builtin_extra cherry cherry-pick format-patch fsck-objects init merge-subtree restore show ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-12 14:19 ` Jeff King @ 2020-08-12 15:56 ` Sibi Siddharthan 2020-08-12 16:06 ` Jeff King 0 siblings, 1 reply; 15+ messages in thread From: Sibi Siddharthan @ 2020-08-12 15:56 UTC (permalink / raw) To: Jeff King; +Cc: Johannes Schindelin, Junio C Hamano, git On Wed, Aug 12, 2020 at 7:50 PM Jeff King <peff@peff.net> wrote: > > On Wed, Aug 12, 2020 at 03:35:06PM +0200, Johannes Schindelin wrote: > > > > That was my philosophy, too, but it's annoying in the meantime as I get > > > a notification for "your build is broken" every time I run CI. So it > > > becomes a game of chicken over who gets annoyed first. ;) > > > > I am a bit sad to read all this, as I thought that we had reached > > consensus that the `Makefile` _is_ the source of truth. > > > > But then, most of the source files that need to be compiled _are_ parsed > > from the Makefile. > > > > So I wonder what problems you ran into; Maybe we can come up with a > > strategy how to preempt future instances of the same nature? > > There are definitely a lot of lists that are copied from the Makefile > into CMakeLists. For some concrete data, here are the patches I needed > for two of my topics. > > This first one is for a topic that remotes git-remote-testsvn and > associated code. The reason for verbosely specifying the test programs (test-tool, test-fake-ssh,etc) was that test-tool required all the objects specified by TEST_BUILTIN_OBJS, whereas test-fake-ssh requires only test-fake-ssh.o. > This second one is for a topic which moved some credential programs into > builtins (since they link libgit.a and nothing else, there's no reason > for them to take up extra space on disk). Even if we read more lists > from the Makefile, I think these hunks still would have needed to be > modified in CMakeLists because I changed the way they interact with > NO_UNIX_SOCKETS (instead of not building credential-cache in that case, > we get a builtin that says "sorry, this was built with > NO_UNIX_SOCKETS"). > For git programs like git-bugreport, git-imap-send which are specified with PROGRAM_OBJS, we don't know which of them require to be linked with libcurl or libexpat. That was the reason these programs were specified verbosely in the CMakeLists. In the future if a new program would be added we need to add them to the PROGRAMS_BUILT list in CMakeLists as well and link it with its library dependencies. Changing the interaction with NO_UNIX_SOCKETS variable will require a change in the CMakeLists file as well. The CMake script was not intended to be a write once and forget situation, it tries to pull from the Makefile as much as possible. A few changes are needed, which I intend to do. Thank You, Sibi Siddharthan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-12 15:56 ` Sibi Siddharthan @ 2020-08-12 16:06 ` Jeff King 2020-08-12 19:53 ` Junio C Hamano 2020-08-14 12:08 ` Johannes Schindelin 0 siblings, 2 replies; 15+ messages in thread From: Jeff King @ 2020-08-12 16:06 UTC (permalink / raw) To: Sibi Siddharthan; +Cc: Johannes Schindelin, Junio C Hamano, git On Wed, Aug 12, 2020 at 09:26:05PM +0530, Sibi Siddharthan wrote: > The CMake script was not intended to be a write once and forget > situation, it tries to pull from the Makefile as much > as possible. A few changes are needed, which I intend to do. Yeah, I know. My main beef was that because it fails CI, the urgency of doing that fix gets pushed onto people working on their individual topics (in fact there is nothing for you to fix yet because I haven't even sent these topics upstream). I don't know how to solve that without stopping its use in the vsbuild CI job, though. And clearly we need _something_ to generate the build data for that job. So this may be the last bad thing. From my perspective as somebody who does not work on Windows, I wonder how much value there is in running vsbuild _and_ Windows CI for average developers. I have certainly gotten information from these jobs (e.g., when introducing a portability problem, or missing a refactoring spot in Windows-only code). But I don't think I've ever gotten information from vsbuild that wasn't also in the regular windows build. -Peff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-12 16:06 ` Jeff King @ 2020-08-12 19:53 ` Junio C Hamano 2020-08-12 20:11 ` Jeff King 2020-08-14 12:08 ` Johannes Schindelin 1 sibling, 1 reply; 15+ messages in thread From: Junio C Hamano @ 2020-08-12 19:53 UTC (permalink / raw) To: Jeff King; +Cc: Sibi Siddharthan, Johannes Schindelin, git Jeff King <peff@peff.net> writes: > Yeah, I know. My main beef was that because it fails CI, the urgency of > doing that fix gets pushed onto people working on their individual > topics (in fact there is nothing for you to fix yet because I haven't > even sent these topics upstream). I don't know how to solve that without > stopping its use in the vsbuild CI job, though. What I am not getting is in what way it blocks you (or others who do not deeply care about Windows) to leave vsbuild CI job broken. Do you have some automation that is gated by all the CI jobs to pass, or do you just dislike failing CI jobs out of principle? I pretty much got used to seeing occasional failures and learned to ignore it (e.g. https://travis-ci.org/github/git/git/jobs/716661598 that ends with Makefile:2467: *** unterminated variable reference. Stop. make: *** Waiting for unfinished jobs.... ). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-12 19:53 ` Junio C Hamano @ 2020-08-12 20:11 ` Jeff King 0 siblings, 0 replies; 15+ messages in thread From: Jeff King @ 2020-08-12 20:11 UTC (permalink / raw) To: Junio C Hamano; +Cc: Sibi Siddharthan, Johannes Schindelin, git On Wed, Aug 12, 2020 at 12:53:39PM -0700, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > Yeah, I know. My main beef was that because it fails CI, the urgency of > > doing that fix gets pushed onto people working on their individual > > topics (in fact there is nothing for you to fix yet because I haven't > > even sent these topics upstream). I don't know how to solve that without > > stopping its use in the vsbuild CI job, though. > > What I am not getting is in what way it blocks you (or others who do > not deeply care about Windows) to leave vsbuild CI job broken. Do > you have some automation that is gated by all the CI jobs to pass, > or do you just dislike failing CI jobs out of principle? It's two things. The first is "out of principle". If the vs-build job always fails, then I'll stop looking at it. So I'd never even see if it fails for a legitimately interesting reason. And now there's no value in running it at all. The second thing is annoyance. I get an email that says "hey, your CI job failed". And then I think "oh no, I should figure out what it is". And then I spend 10 minutes investigating only to find out that no, it's not something I care about. If the vs-build job always failed I could write it off in less time than 10 minutes. But it's still not nothing, because the email still grabs my attention, and then I have to manually figure out that it was indeed vs-build and only vs-build which failed (which is not helped by the mail from GitHub consisting of 25 lines listing the succeeded jobs). Getting that once a day isn't world-ending, but it is annoying (and I do get it once a day because I do my own daily integration run, which is what I push to CI). So rather than deal with that, I'd probably add more bits to our ci/config to allow myself to just disable that job. For now I'm letting it run, though. I've fixed my two topics, and I'm curious to see if it comes up again, and if so how long it takes. -Peff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-12 16:06 ` Jeff King 2020-08-12 19:53 ` Junio C Hamano @ 2020-08-14 12:08 ` Johannes Schindelin 2020-08-14 12:40 ` Jeff King 1 sibling, 1 reply; 15+ messages in thread From: Johannes Schindelin @ 2020-08-14 12:08 UTC (permalink / raw) To: Jeff King; +Cc: Sibi Siddharthan, Junio C Hamano, git Hi Peff, On Wed, 12 Aug 2020, Jeff King wrote: > From my perspective as somebody who does not work on Windows, I wonder > how much value there is in running vsbuild _and_ Windows CI for average > developers. I have certainly gotten information from these jobs (e.g., > when introducing a portability problem, or missing a refactoring spot in > Windows-only code). But I don't think I've ever gotten information from > vsbuild that wasn't also in the regular windows build. There have not been a _ton_ of these instances, but there have been a couple: 2049b8dc65e (diffcore_rename(): use a stable sort, 2019-09-30) Here, MSVC pointed out that `qsort()` does not need to be stable, yet our test suite claimed that we expect it to be. 116d1fa6c69 (vreportf(): avoid relying on stdio buffering, 2019-10-30) MSVC's code demonstrated that `fprintf()` prints out messages character by character. c097b95a260 (msvc: avoid using minus operator on unsigned types, 2019-10-04) We relied on some iffy behavior of GNU C which allows negating unsigned values (which cannot work if the high bit is set already). dbcd970c27b (push: do not pretend to return `int` from `die_push_simple()`, 2019-09-30) A non-void return type in a noreturn function is bogus. fdda1ac62d7 (t0001 (mingw): do not expect a specific order of stdout/stderr, 2019-06-19) A test that might even have been flaky on Linux failed frequently due to an incorrect assumption whether `stdout` would be flushed before `stderr`. I cannot find any more instances, so yes, I agree that the `vs-build`/`vs-test` jobs might not be _all_ that necessary. So maybe we should do something like this? -- snipsnap -- diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 30425404eb3..2549fff8edd 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -122,7 +122,7 @@ jobs: path: ${{env.FAILED_TEST_ARTIFACTS}} vs-build: needs: ci-config - if: needs.ci-config.outputs.enabled == 'yes' + if: (github.repository == 'git/git' || github.repository == 'gitgitgadget/git') && needs.ci-config.outputs.enabled == 'yes' env: MSYSTEM: MINGW64 NO_PERL: 1 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-14 12:08 ` Johannes Schindelin @ 2020-08-14 12:40 ` Jeff King 2020-08-17 4:41 ` Johannes Schindelin 2020-08-17 17:19 ` Junio C Hamano 0 siblings, 2 replies; 15+ messages in thread From: Jeff King @ 2020-08-14 12:40 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Sibi Siddharthan, Junio C Hamano, git On Fri, Aug 14, 2020 at 02:08:28PM +0200, Johannes Schindelin wrote: > On Wed, 12 Aug 2020, Jeff King wrote: > > > From my perspective as somebody who does not work on Windows, I wonder > > how much value there is in running vsbuild _and_ Windows CI for average > > developers. I have certainly gotten information from these jobs (e.g., > > when introducing a portability problem, or missing a refactoring spot in > > Windows-only code). But I don't think I've ever gotten information from > > vsbuild that wasn't also in the regular windows build. > > There have not been a _ton_ of these instances, but there have been a > couple: Thanks, that was exactly the kind of data I was interested in. > I cannot find any more instances, so yes, I agree that the > `vs-build`/`vs-test` jobs might not be _all_ that necessary. So maybe we > should do something like this? Let's leave it be for now. The topics I had to adjust due to cmake were ones that I'd had sitting around for a while. So while I hit problems immediately, now that the queue is drained it's not clear to me how often it will come up in practice. > -- snipsnap -- > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml > index 30425404eb3..2549fff8edd 100644 > --- a/.github/workflows/main.yml > +++ b/.github/workflows/main.yml > @@ -122,7 +122,7 @@ jobs: > path: ${{env.FAILED_TEST_ARTIFACTS}} > vs-build: > needs: ci-config > - if: needs.ci-config.outputs.enabled == 'yes' > + if: (github.repository == 'git/git' || github.repository == 'gitgitgadget/git') && needs.ci-config.outputs.enabled == 'yes' If we do go this route, I'd consider defaulting it to on and just letting people disable it through needs.ci-config.outputs.vsbuild or similar. -Peff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-14 12:40 ` Jeff King @ 2020-08-17 4:41 ` Johannes Schindelin 2020-08-17 17:19 ` Junio C Hamano 1 sibling, 0 replies; 15+ messages in thread From: Johannes Schindelin @ 2020-08-17 4:41 UTC (permalink / raw) To: Jeff King; +Cc: Sibi Siddharthan, Junio C Hamano, git Hi Peff, On Fri, 14 Aug 2020, Jeff King wrote: > On Fri, Aug 14, 2020 at 02:08:28PM +0200, Johannes Schindelin wrote: > > > On Wed, 12 Aug 2020, Jeff King wrote: > > > > > From my perspective as somebody who does not work on Windows, I wonder > > > how much value there is in running vsbuild _and_ Windows CI for average > > > developers. I have certainly gotten information from these jobs (e.g., > > > when introducing a portability problem, or missing a refactoring spot in > > > Windows-only code). But I don't think I've ever gotten information from > > > vsbuild that wasn't also in the regular windows build. > > > > There have not been a _ton_ of these instances, but there have been a > > couple: > > Thanks, that was exactly the kind of data I was interested in. > > > I cannot find any more instances, so yes, I agree that the > > `vs-build`/`vs-test` jobs might not be _all_ that necessary. So maybe we > > should do something like this? > > Let's leave it be for now. The topics I had to adjust due to cmake were > ones that I'd had sitting around for a while. So while I hit problems > immediately, now that the queue is drained it's not clear to me how > often it will come up in practice. > > > -- snipsnap -- > > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml > > index 30425404eb3..2549fff8edd 100644 > > --- a/.github/workflows/main.yml > > +++ b/.github/workflows/main.yml > > @@ -122,7 +122,7 @@ jobs: > > path: ${{env.FAILED_TEST_ARTIFACTS}} > > vs-build: > > needs: ci-config > > - if: needs.ci-config.outputs.enabled == 'yes' > > + if: (github.repository == 'git/git' || github.repository == 'gitgitgadget/git') && needs.ci-config.outputs.enabled == 'yes' > > If we do go this route, I'd consider defaulting it to on and just > letting people disable it through needs.ci-config.outputs.vsbuild or > similar. Okay, let's leave it for now, and if there are more instances, go the `config-repo/ci/config/` route. Ciao, Dscho ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-14 12:40 ` Jeff King 2020-08-17 4:41 ` Johannes Schindelin @ 2020-08-17 17:19 ` Junio C Hamano 1 sibling, 0 replies; 15+ messages in thread From: Junio C Hamano @ 2020-08-17 17:19 UTC (permalink / raw) To: Jeff King; +Cc: Johannes Schindelin, Sibi Siddharthan, git Jeff King <peff@peff.net> writes: >> - if: needs.ci-config.outputs.enabled == 'yes' >> + if: (github.repository == 'git/git' || github.repository == 'gitgitgadget/git') && needs.ci-config.outputs.enabled == 'yes' > > If we do go this route, I'd consider defaulting it to on and just > letting people disable it through needs.ci-config.outputs.vsbuild or > similar. That sounds like a good idea. Special casing based on repositories do not scale. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Aug 2020, #01; Mon, 3) 2020-08-04 5:35 What's cooking in git.git (Aug 2020, #01; Mon, 3) Junio C Hamano 2020-08-04 18:50 ` Jeff King @ 2020-08-06 3:25 ` Jiang Xin 1 sibling, 0 replies; 15+ messages in thread From: Jiang Xin @ 2020-08-06 3:25 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List Junio C Hamano <gitster@pobox.com> 于2020年8月4日周二 下午1:37写道: > > -------------------------------------------------- > [Stalled] > > * jx/proc-receive-hook (2020-05-18) 11 commits > . doc: add documentation for the proc-receive hook > . transport: parse report options for tracking refs > . t5411: test updates of remote-tracking branches > . receive-pack: new config receive.procReceiveRefs > . refs.c: refactor to reuse ref_is_hidden() > . receive-pack: feed report options to post-receive > . doc: add document for capability report-status-v2 > . New capability "report-status-v2" for git-push > . receive-pack: add new proc-receive hook > . t5411: add basic test cases for proc-receive hook > . transport: not report a non-head push as a branch > > "git receive-pack" that accepts requests by "git push" learned to > outsource most of the ref updates to the new "proc-receive" hook. > > Ejected out of 'seen'; somehow its tests seem to break with clang > cf. https://travis-ci.org/github/git/git/builds/713443572 Will check the build log. BTW, I want to extend the syntax of the config variable "receive.procReceiveRef" like this: git config receive.procReceiveRef "kind:new,remove" So "receive-pack" can pass commands for creating or removing tags/branches to "proc-receive" to create pull request for these operations. -- Jiang Xin ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-08-17 17:27 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-08-04 5:35 What's cooking in git.git (Aug 2020, #01; Mon, 3) Junio C Hamano 2020-08-04 18:50 ` Jeff King 2020-08-04 18:58 ` Junio C Hamano 2020-08-04 19:20 ` Jeff King 2020-08-12 13:35 ` Johannes Schindelin 2020-08-12 14:19 ` Jeff King 2020-08-12 15:56 ` Sibi Siddharthan 2020-08-12 16:06 ` Jeff King 2020-08-12 19:53 ` Junio C Hamano 2020-08-12 20:11 ` Jeff King 2020-08-14 12:08 ` Johannes Schindelin 2020-08-14 12:40 ` Jeff King 2020-08-17 4:41 ` Johannes Schindelin 2020-08-17 17:19 ` Junio C Hamano 2020-08-06 3:25 ` Jiang Xin
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).