What's cooking in git.git (Aug 2020, #01; Mon, 3)

What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Jeff King]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Junio C Hamano]

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 ;-)

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Jeff King]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Jiang Xin]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Johannes Schindelin]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Jeff King]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Sibi Siddharthan]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Jeff King]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Junio C Hamano]

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....

).

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Jeff King]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Johannes Schindelin]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Jeff King]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Johannes Schindelin]

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

Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)

[Junio C Hamano]

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.