All of lore.kernel.org
 help / color / mirror / Atom feed
* What's cooking in git.git (May 2020, #09; Tue, 26)
@ 2020-05-26 18:47 Junio C Hamano
  2020-05-27  3:27 ` jn/experimental-opts-into-proto-v2, was " Johannes Schindelin
  0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2020-05-26 18:47 UTC (permalink / raw)
  To: git

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in '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.

Git 2.27-rc2 has been tagged.

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

--------------------------------------------------
[Graduated to "master"]

* ss/faq-ignore (2020-05-25) 1 commit
  (merged to 'next' on 2020-05-25 at f2f7dd2ff6)
 + gitfaq: avoid validation error with older asciidoc

 Doc markup fix.

--------------------------------------------------
[New Topics]

* en/sparse-with-submodule-doc (2020-05-25) 1 commit
 - git-sparse-checkout: clarify interactions with submodules


* ma/rev-list-options-docfix (2020-05-26) 1 commit
 - rev-list-options.txt: start a list for `show-pulls`

--------------------------------------------------
[Stalled]

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


* jk/complete-git-switch (2020-04-28) 11 commits
 - completion: complete remote branches for git switch --track
 - completion: recognize -c/-C when completing for git switch
 - completion: fix completion for git switch with no options
 - completion: perform DWIM logic directly in __git_complete_refs
 - completion: extract function __git_dwim_remote_heads
 - completion: rename --track option of __git_complete_refs
 - completion: stop completing refs for git switch --orphan
 - completion: add tests showing lack of support for git switch -c/-C
 - completion: add test highlighting subpar git switch --track completion
 - completion: add test showing subpar git switch completion
 - completion: add some simple test cases for git switch completion

 The command line completion (in contrib/) learned to complete
 options that the "git switch" command takes.

 Needs review.


* dl/test-must-fail-fixes-5 (2020-05-21) 5 commits
 - lib-submodule-update: pass OVERWRITING_FAIL
 - SQUASH???  <20200521112545.GB581643@generichostname>
 - lib-submodule-update: prepend "git" to $command
 - lib-submodule-update: consolidate --recurse-submodules
 - lib-submodule-update: add space after function name

 The effort to avoid using test_must_fail on non-git command continues.

 Waiting for a review thread to settle.
 cf. <20200521182928.GA1308647@coredump.intra.peff.net>
 The last step is a bit too ugly to live; Peff seems to have better
 ideas.


* mr/bisect-in-c-2 (2020-04-23) 12 commits
 - 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--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: fix `cmd_*()` function switch default return

 Rewrite of the remainder of "git bisect" script in C continues.

 Expecting a response to reviews.
 cf. <nycvar.QRO.7.76.6.2005230007260.56@tvgsbejvaqbjf.bet>


* 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]

* bc/filter-process (2020-05-21) 2 commits
  (merged to 'next' on 2020-05-24 at 3d51328096)
 + t2060: add a test for switch with --orphan and --discard-changes
 + builtin/checkout: simplify metadata initialization

 Code simplification and test coverage enhancement.

 Will cook in 'next'.


* cb/bisect-helper-parser-fix (2020-05-24) 1 commit
  (merged to 'next' on 2020-05-24 at d30e10fa86)
 + bisect--helper: avoid segfault with bad syntax in `start --term-*`

 The code to parse "git bisect start" command line was lax in
 validating the arguments.

 Will cook in 'next'.


* jn/experimental-opts-into-proto-v2 (2020-05-21) 1 commit
  (merged to 'next' on 2020-05-24 at 53cd664dfe)
 + config: let feature.experimental imply protocol.version=2

 "feature.experimental" configuration variable is to let volunteers
 easily opt into a set of newer features, which use of the v2
 transport protocol is now a part of.

 Will cook in 'next'.


* jx/pkt-line-doc-count-fix (2020-05-21) 1 commit
  (merged to 'next' on 2020-05-24 at 7115240db4)
 + doc: fix wrong 4-byte length of pkt-line message

 Docfix.

 Will cook in 'next'.


* rs/fsck-duplicate-names-in-trees (2020-05-21) 4 commits
  (merged to 'next' on 2020-05-24 at 6e1d6ba087)
 + fsck: detect more in-tree d/f conflicts
 + t1450: demonstrate undetected in-tree d/f conflict
 + t1450: increase test coverage of in-tree d/f detection
 + fsck: fix a typo in a comment

 The check in "git fsck" to ensure that the tree objects are sorted
 still had corner cases it missed unsorted entries.

 Will cook in 'next'.


* ss/submodule-set-branch-in-c (2020-05-24) 2 commits
 - fixup! submodule: port subcommand 'set-branch' from shell to C
 - submodule: port subcommand 'set-branch' from shell to C

 Rewrite of parts of the scripted "git submodule" Porcelain command
 continues; this time it is "git submodule set-branch" subcommand's
 turn.

 cf. <20200523231838.GB1981@danh.dev>


* vs/complete-stash-show-p-fix (2020-05-21) 1 commit
  (merged to 'next' on 2020-05-24 at fcbff29a0f)
 + completion: don't override given stash subcommand with -p

 The command line completion script (in contrib/) tried to complete
 "git stash -p" as if it were "git stash push -p", but it was too
 aggressive and also affected "git stash show -p", which has been
 corrected.

 Will cook in 'next'.


* cb/t5608-cleanup (2020-05-24) 1 commit
  (merged to 'next' on 2020-05-24 at 2bfa581890)
 + t5608: avoid say() and use "skip_all" instead for consistency

 Test fixup.

 Will cook in 'next'.


* es/config-hooks (2020-05-21) 4 commits
 . hook: add --porcelain to list command
 . hook: add list command
 . hook: scaffolding for git-hook subcommand
 . doc: propose hooks managed by the config


* rs/checkout-b-track-error (2020-05-24) 2 commits
  (merged to 'next' on 2020-05-26 at 9220e43203)
 + checkout: improve error messages for -b with extra argument
 + checkout: add tests for -b and --track

 The error message from "git checkout -b foo -t bar baz" was
 confusing.

 Will cook in 'next'.


* lo/sparse-universal-zero-init (2020-05-24) 1 commit
  (merged to 'next' on 2020-05-24 at 1f4ea6b348)
 + sparse: allow '{ 0 }' to be used without warnings

 We've adopted a convention that any on-stack structure can be
 initialized to have zero values in all fields with "= { 0 }", even
 when the first field happens to be a pointer, but sparse complained
 that a null pointer should be spelled NULL for a long time.  Start
 using -Wno-universal-initializer option to squelch it.

 Will cook in 'next'.


* pw/rebase-i-more-options (2020-05-24) 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.

 Expecting the final touch
 cf. <20200523155203.GA10163@danh.dev>


* an/merge-single-strategy-optim (2020-05-19) 1 commit
  (merged to 'next' on 2020-05-20 at 8d5cacc8d1)
 + merge: optimization to skip evaluate_result for single strategy

 Code optimization for a common case.

 Will cook in 'next'.


* cc/upload-pack-data (2020-05-18) 13 commits
 - upload-pack: use upload_pack_data fields in receive_needs()
 - upload-pack: pass upload_pack_data to create_pack_file()
 - upload-pack: remove static variable 'stateless_rpc'
 - upload-pack: pass upload_pack_data to check_non_tip()
 - upload-pack: pass upload_pack_data to send_ref()
 - upload-pack: move symref to upload_pack_data
 - upload-pack: use upload_pack_data writer in receive_needs()
 - upload-pack: pass upload_pack_data to receive_needs()
 - upload-pack: pass upload_pack_data to get_common_commits()
 - upload-pack: use 'struct upload_pack_data' in upload_pack()
 - upload-pack: move 'struct upload_pack_data' around
 - upload-pack: move {want,have}_obj to upload_pack_data
 - upload-pack: remove unused 'wants' from upload_pack_data

 Code clean-up.


* dl/remote-curl-deadlock-fix (2020-05-24) 7 commits
  (merged to 'next' on 2020-05-26 at 072714ca7f)
 + stateless-connect: send response end packet
 + pkt-line: define PACKET_READ_RESPONSE_END
 + remote-curl: error on incomplete packet
 + pkt-line: extern packet_length()
 + transport: extract common fetch_pack() call
 + remote-curl: remove label indentation
 + remote-curl: fix typo

 On-the-wire protocol v2 easily falls into a deadlock between the
 remote-curl helper and the fetch-pack process when the server side
 prematurely throws an error and disconnects.  The communication has
 been updated to make it more robust.

 Will cook in 'next'.


* jk/ci-only-on-selected-branches (2020-05-18) 1 commit
  (merged to 'next' on 2020-05-24 at 5f1f5ef66a)
 + ci/config: correct instruction for CI preferences

 Dev support.

 Will merge to 'master'.


* la/diff-relative-config (2020-05-24) 1 commit
  (merged to 'next' on 2020-05-26 at b4604e6abc)
 + diff: add config option relative

 The commands in the "diff" family learned to honor "diff.relative"
 configuration variable.

 Will cook in 'next'.


* cb/t4210-illseq-auto-detect (2020-05-18) 2 commits
  (merged to 'next' on 2020-05-24 at c03b4095fa)
 + t4210: detect REG_ILLSEQ dynamically and skip affected tests
 + t/helper: teach test-regex to report pattern errors (like REG_ILLSEQ)

 As FreeBSD is not the only platform whose regexp library reports
 a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that
 automatically and skip the affected tests.

 Will cook in 'next'.


* bk/p4-prepare-p4-only-fix (2020-05-12) 1 commit
  (merged to 'next' on 2020-05-24 at c1b4644b04)
 + git-p4.py: fix --prepare-p4-only error with multiple commits

 The "--prepare-p4-only" option is supposed to stop after replaying
 one changeset, but kept going (by mistake?)

 Will cook in 'next'.
 cf. <CAE5ih797YYxsR2H0TA65w9W-1jF4jQLayja_nGjQMGtc=PB6Jw@mail.gmail.com>


* jt/curl-verbose-on-trace-curl (2020-05-11) 2 commits
  (merged to 'next' on 2020-05-11 at 814e31b9d4)
 + http, imap-send: stop using CURLOPT_VERBOSE
 + t5551: test that GIT_TRACE_CURL redacts password

 Rewrite support for GIT_CURL_VERBOSE in terms of GIT_TRACE_CURL.

 Expecting further work on optionally disabling redacting authinfo


* mt/grep-sparse-checkout (2020-05-11) 4 commits
 - config: add setting to ignore sparsity patterns in some cmds
 - grep: honor sparse checkout patterns
 - config: load the correct config.worktree file
 - doc: grep: unify info on configuration variables

 "git grep" has been tweaked to be limited to the sparse checkout
 paths.

 Expecting further polishing.
 cf. <CAHd-oW6BoHkMSAQVquHR+H7=g84VE-qmXGYcDmWwFxuLyqZSzg@mail.gmail.com>


* bc/sha-256-part-2 (2020-05-13) 44 commits
 - remote-testgit: adapt for object-format
 - bundle: detect hash algorithm when reading refs
 - t5300: pass --object-format to git index-pack
 - t5703: use object-format serve option
 - t5702: offer an object-format capability in the test
 - t/helper: initialize the repository for test-sha1-array
 - remote-curl: avoid truncating refs with ls-remote
 - t1050: pass algorithm to index-pack when outside repo
 - builtin/index-pack: add option to specify hash algorithm
 - remote-curl: detect algorithm for dumb HTTP by size
 - builtin/ls-remote: initialize repository based on fetch
 - t5500: make hash independent
 - serve: advertise object-format capability for protocol v2
 - connect: parse v2 refs with correct hash algorithm
 - connect: pass full packet reader when parsing v2 refs
 - Documentation/technical: document object-format for protocol v2
 - t1302: expect repo format version 1 for SHA-256
 - builtin/show-index: provide options to determine hash algo
 - t5302: modernize test formatting
 - packfile: compute and use the index CRC offset
 - t3200: mark assertion with SHA1 prerequisite
 - setup: set the_repository's hash algo when checking format
 - fetch-pack: parse and advertise the object-format capability
 - t5704: send object-format capability with SHA-256
 - t5562: pass object-format in synthesized test data
 - builtin/clone: initialize hash algorithm properly
 - remote-curl: implement object-format extensions
 - transport-helper: implement object-format extensions
 - docs: update remote helper docs for object-format extensions
 - builtin/receive-pack: detect when the server doesn't support our hash
 - connect: detect algorithm when fetching refs
 - fetch-pack: detect when the server doesn't support our hash
 - connect: make parse_feature_value extern
 - send-pack: detect when the server doesn't support our hash
 - connect: add function to detect supported v1 hash functions
 - transport: add a hash algorithm member
 - pkt-line: add a member for hash algorithm
 - connect: add function to fetch value of a v2 server capability
 - connect: add function to parse multiple v1 capability values
 - remote: advertise the object-format capability on the server side
 - wrapper: add function to compare strings with different NUL termination
 - connect: have ref processing code take struct packet_reader
 - Documentation: document v1 protocol object-format capability
 - t1050: match object ID paths in a hash-insensitive way

 SHA-256 migration work continues.


* es/bugreport-shell (2020-05-12) 2 commits
  (merged to 'next' on 2020-05-24 at 79c5c8308b)
 + bugreport: include user interactive shell
 + help: add shell-path to --build-options

 "git bugreport" learns to report what shell is in use.

 Will cook in 'next'.
 We may want to learn more details than just the path, but
 that can come later.
 cf. <20200512235924.GC6605@camp.crustytoothpaste.net>


* ds/line-log-on-bloom (2020-05-11) 5 commits
  (merged to 'next' on 2020-05-11 at 046d49d455)
 + line-log: integrate with changed-path Bloom filters
 + line-log: try to use generation number-based topo-ordering
 + line-log: more responsive, incremental 'git log -L'
 + t4211-line-log: add tests for parent oids
 + line-log: remove unused fields from 'struct line_log_data'

 "git log -L..." now takes advantage of the "which paths are touched
 by this commit?" info stored in the commit-graph system.

 Will cook in 'next'.


* tb/commit-graph-no-check-oids (2020-05-18) 8 commits
  (merged to 'next' on 2020-05-24 at 72bd1063ca)
 + commit-graph: drop COMMIT_GRAPH_WRITE_CHECK_OIDS flag
 + t5318: reorder test below 'graph_read_expect'
 + commit-graph.c: simplify 'fill_oids_from_commits'
 + builtin/commit-graph.c: dereference tags in builtin
 + builtin/commit-graph.c: extract 'read_one_commit()'
 + commit-graph.c: peel refs in 'add_ref_to_set'
 + commit-graph.c: show progress of finding reachable commits
 + commit-graph.c: extract 'refs_cb_data'

 Clean-up the commit-graph codepath.

 Will cook in 'next'.


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

 Needs review.


* hn/refs-cleanup (2020-05-20) 6 commits
  (merged to 'next' on 2020-05-24 at dd9b665698)
 + reftable: define version 2 of the spec to accomodate SHA256
 + reftable: clarify how empty tables should be written
 + reftable: file format documentation
 + refs: improve documentation for ref iterator
 + t: use update-ref and show-ref to reading/writing refs
 + refs.h: clarify reflog iteration order
 (this branch is used by hn/reftable.)

 Preliminary clean-ups around refs API, plus file format
 specification documentation for the reftable backend.

 Will cook in 'next'.


* hn/reftable (2020-05-20) 9 commits
 - Add reftable testing infrastructure
 - vcxproj: adjust for the reftable changes
 - Add GIT_DEBUG_REFS debugging mechanism
 - Reftable support for git-core
 - Add reftable library
 - Add .gitattributes for the reftable/ directory
 - Iterate over the "refs/" namespace in for_each_[raw]ref
 - Move REF_LOG_ONLY to refs-internal.h
 - Write pseudorefs through ref backends.
 (this branch uses hn/refs-cleanup.)

 A new refs backend "reftable" to replace the traditional
 combination of packed-refs files and one-file-per-ref loose refs
 has been implemented and integrated for improved performance and
 atomicity.

 Needs review.

--------------------------------------------------
[Discarded]

* jc/credential-store-file-format-doc (2020-04-27) 1 commit
 . credential-store: document the file format a bit more

 Now has become a part of Carlo's credential-store fix patches.


* js/ci-skip-on-github-workflow (2020-05-02) 1 commit
 . ci: respect the [skip ci] convention in our GitHub workflow "CI/PR"

 Allow contributors to mark a branch/push that it does not have to
 be built via GitHub actions, in a way similar to how Travis lets
 them mark the commits with an embedded "[skip ci]" string.

 Superseded by dd/ci-only-on-selective-branches topic.


* dd/ci-only-on-selective-branches (2020-05-05) 2 commits
 - CI: limit GitHub Actions to designated branches
 - SubmittingPatches: advertise GitHub Actions CI

 Instead of always building all branches of all forks of our project
 at GitHub via GitHub Actions, only build when branches with known
 and specific names are updated, and also a pull request.

 Superseded by jk/ci-only-on-selected-branches

^ permalink raw reply	[flat|nested] 7+ messages in thread

* jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)
  2020-05-26 18:47 What's cooking in git.git (May 2020, #09; Tue, 26) Junio C Hamano
@ 2020-05-27  3:27 ` Johannes Schindelin
  2020-05-27 21:49   ` Junio C Hamano
  0 siblings, 1 reply; 7+ messages in thread
From: Johannes Schindelin @ 2020-05-27  3:27 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi Junio,

On Tue, 26 May 2020, Junio C Hamano wrote:

> * jn/experimental-opts-into-proto-v2 (2020-05-21) 1 commit
>   (merged to 'next' on 2020-05-24 at 53cd664dfe)
>  + config: let feature.experimental imply protocol.version=2
>
>  "feature.experimental" configuration variable is to let volunteers
>  easily opt into a set of newer features, which use of the v2
>  transport protocol is now a part of.
>
>  Will cook in 'next'.

Given that the `feature.experimental` option is supposed to increase
testing in the wild, sort of `next` but for users rather than developers
who build their own Git, could we maybe integrate this into v2.27.0,
still?

Thanks,
Dscho

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)
  2020-05-28  0:43       ` Junio C Hamano
@ 2020-05-27 20:05         ` Johannes Schindelin
  2020-05-28 14:44           ` Junio C Hamano
  0 siblings, 1 reply; 7+ messages in thread
From: Johannes Schindelin @ 2020-05-27 20:05 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jonathan Nieder, git

Hi Junio,

On Wed, 27 May 2020, Junio C Hamano wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:
>
> >> I have been wondering about the same thing, and if it were not using
> >> its own custom way to read the configuration, it would have been a
> >> non-brainer to merge it down before the release.
> >
> > Hm, do you have more detail about this?  git_config_get_bool feels
> > very standard and non-custom.
> >
> > Do you mean that you would like it to go in repo-settings.c?
>
> No.  I fully accept your reasoning in the proposed log message why a
> handcrafted query to the config system is done in the location the
> patch adds a call.

Now, I apologize. I had not reviewed the patch, and only just read it.

I agree that it is a bit unfortunate that it uses such a non-standard way
that hard-codes "feature.experimental" in a different place than
repo-settings.c.

And I have to admit that the `git ls-remote` example does not really
convince me that it makes sense to go a different route than all other
experimental options. It makes it unnecessarily hard to gather the list of
features enabled via `features.experimental = true`.

Had it been a patch to repo-settings.c, I would now have tried to lobby
for including it into v2.27.0, but as it is, I fully agree with your
reasoning to just leave it out.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)
  2020-05-27  3:27 ` jn/experimental-opts-into-proto-v2, was " Johannes Schindelin
@ 2020-05-27 21:49   ` Junio C Hamano
  2020-05-27 23:58     ` Jonathan Nieder
  0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2020-05-27 21:49 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Tue, 26 May 2020, Junio C Hamano wrote:
>
>> * jn/experimental-opts-into-proto-v2 (2020-05-21) 1 commit
>>   (merged to 'next' on 2020-05-24 at 53cd664dfe)
>>  + config: let feature.experimental imply protocol.version=2
>>
>>  "feature.experimental" configuration variable is to let volunteers
>>  easily opt into a set of newer features, which use of the v2
>>  transport protocol is now a part of.
>>
>>  Will cook in 'next'.
>
> Given that the `feature.experimental` option is supposed to increase
> testing in the wild, sort of `next` but for users rather than developers
> who build their own Git, could we maybe integrate this into v2.27.0,
> still?

I have been wondering about the same thing, and if it were not using
its own custom way to read the configuration, it would have been a
non-brainer to merge it down before the release.  But this late in
the cycle, I'd rather not.

Thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)
  2020-05-27 21:49   ` Junio C Hamano
@ 2020-05-27 23:58     ` Jonathan Nieder
  2020-05-28  0:43       ` Junio C Hamano
  0 siblings, 1 reply; 7+ messages in thread
From: Jonathan Nieder @ 2020-05-27 23:58 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, git

Hi,

Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> On Tue, 26 May 2020, Junio C Hamano wrote:

>>> * jn/experimental-opts-into-proto-v2 (2020-05-21) 1 commit
>>>   (merged to 'next' on 2020-05-24 at 53cd664dfe)
>>>  + config: let feature.experimental imply protocol.version=2
>>>
>>>  "feature.experimental" configuration variable is to let volunteers
>>>  easily opt into a set of newer features, which use of the v2
>>>  transport protocol is now a part of.
>>>
>>>  Will cook in 'next'.
>>
>> Given that the `feature.experimental` option is supposed to increase
>> testing in the wild, sort of `next` but for users rather than developers
>> who build their own Git, could we maybe integrate this into v2.27.0,
>> still?

Yes, that was my hope when writing it.

> I have been wondering about the same thing, and if it were not using
> its own custom way to read the configuration, it would have been a
> non-brainer to merge it down before the release.

Hm, do you have more detail about this?  git_config_get_bool feels
very standard and non-custom.

Do you mean that you would like it to go in repo-settings.c?

>                                                   But this late in
> the cycle, I'd rather not.

Sure, I can understand.

Would this be something to put on "master" soon after the release?

Dscho, do you think it would be useful for downstreams such as Debian
to apply it?  (For Debian in particular, it's not hard to get "next"
from experimental, so maybe not.)

Thanks,
Jonathan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)
  2020-05-27 23:58     ` Jonathan Nieder
@ 2020-05-28  0:43       ` Junio C Hamano
  2020-05-27 20:05         ` Johannes Schindelin
  0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2020-05-28  0:43 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: Johannes Schindelin, git

Jonathan Nieder <jrnieder@gmail.com> writes:

>> I have been wondering about the same thing, and if it were not using
>> its own custom way to read the configuration, it would have been a
>> non-brainer to merge it down before the release.
>
> Hm, do you have more detail about this?  git_config_get_bool feels
> very standard and non-custom.
>
> Do you mean that you would like it to go in repo-settings.c?

No.  I fully accept your reasoning in the proposed log message why a
handcrafted query to the config system is done in the location the
patch adds a call.  There is nothing wrong with the patch.

But that means that the way it uses the "experimental" variable is
different from the battle-tested way it has been used, which makes
it less than "non-brainer".  It may not be risky after all, but
still.  This late in the cycle, the fewer things we need to worry
about, the better.
>
>>                                                   But this late in
>> the cycle, I'd rather not.
>
> Sure, I can understand.
>
> Would this be something to put on "master" soon after the release?

That was exactly what I had in mind.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)
  2020-05-27 20:05         ` Johannes Schindelin
@ 2020-05-28 14:44           ` Junio C Hamano
  0 siblings, 0 replies; 7+ messages in thread
From: Junio C Hamano @ 2020-05-28 14:44 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Jonathan Nieder, git

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> No.  I fully accept your reasoning in the proposed log message why a
>> handcrafted query to the config system is done in the location the
>> patch adds a call.
>
> Now, I apologize. I had not reviewed the patch, and only just read it.
>
> I agree that it is a bit unfortunate that it uses such a non-standard way
> that hard-codes "feature.experimental" in a different place than
> repo-settings.c.

You make it sound like it was a choice made by the implementation,
but (1) a "non-standard" way may not have to stay non-standard
forever (there may be many more experimental features that are not
tied to a specific repository in the future), and (2) the patch
needs to do it in a way that is not tied to a single repository
because it is not at per-repository level decision.  As long as we
are aware of this limitation caused by the current "experimental"
arrangement that is tied to a repository and can work towards
extending it to support this new use case in the future, I do not
think it is unfortunate at all.

> Had it been a patch to repo-settings.c, I would now have tried to lobby
> for including it into v2.27.0, but as it is, I fully agree with your
> reasoning to just leave it out.

No need to apologize for raising it as an issue---hearing from those
with different risk tolerance from time to time is a good way to
calibrate my own.

Thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-05-28 14:44 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-26 18:47 What's cooking in git.git (May 2020, #09; Tue, 26) Junio C Hamano
2020-05-27  3:27 ` jn/experimental-opts-into-proto-v2, was " Johannes Schindelin
2020-05-27 21:49   ` Junio C Hamano
2020-05-27 23:58     ` Jonathan Nieder
2020-05-28  0:43       ` Junio C Hamano
2020-05-27 20:05         ` Johannes Schindelin
2020-05-28 14:44           ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.