threads / discuss / 53540

What's cooking in git.git (May 2020, #08; Sun, 24)

Subject: What's cooking in git.git (May 2020, #08; Sun, 24)

## tl;dr

7 messages between May 25, 2020 and May 26, 2020.

replies: 6people: 4as markdown or json

Junio C Hamano· May 25, 2020, 03:22 UTC · lore

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 will be tagged soon, but most of the topics planned for it are already in 'master'.

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

* bc/faq (2020-05-20) 1 commit
  (merged to 'next' on 2020-05-21 at ab3fc8fb75)
 + command-list.txt: add gitfaq to the list of guides
 "git help guides" now includes the newly added FAQ document.
* cb/bisect-replay-with-dos-fix (2020-05-20) 1 commit
  (merged to 'next' on 2020-05-21 at ebcc6eb30e)
 + bisect: avoid tailing CR characters from revision in replay
 Re-fix longstanding "edited bisect log may confuse bisect replay
 with trailing carriage-return" issue.
* dd/t5703-grep-a-fix (2020-05-19) 1 commit
  (merged to 'next' on 2020-05-21 at b85828341f)
 + t5703: replace "grep -a" usage by perl
 Update an unconditional use of "grep -a" with a perl script in a test.
* dl/merge-autostash (2020-05-20) 1 commit
  (merged to 'next' on 2020-05-21 at 985d87225d)
 + t5520: avoid alternation in grep's BRE (not POSIX)
 Test fix.
* ds/multi-pack-verify (2020-05-19) 1 commit
  (merged to 'next' on 2020-05-21 at a337d6352c)
 + fsck: use ERROR_MULTI_PACK_INDEX
 Fix for a copy-and-paste error introduced during 2.20 era.
* gp/hppa-stack-test-fix (2020-05-18) 1 commit
  (merged to 'next' on 2020-05-20 at 57ed63b4ad)
 + tests: skip small-stack tests on hppa architecture
 Platform dependent tweak to a test for HP-PA.
* gs/commit-graph-path-filter (2020-05-20) 1 commit
  (merged to 'next' on 2020-05-21 at e563529d0a)
 + t4216: avoid unnecessary subshell in test_bloom_filters_not_used
 Test fix.
* jt/avoid-prefetch-when-able-in-diff (2020-05-19) 1 commit
  (merged to 'next' on 2020-05-21 at 4fa6f05ea4)
 + t4067: make rename detection test output raw diff
 Test-coverage enhancement.
* ma/doc-fixes (2020-05-18) 5 commits
  (merged to 'next' on 2020-05-21 at 0f5e748d23)
 + git-sparse-checkout.txt: add missing '
 + git-credential.txt: use list continuation
 + git-commit-graph.txt: fix list rendering
 + git-commit-graph.txt: fix grammo
 + date-formats.txt: fix list continuation
 Various doc fixes.

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

* 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
 - 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 merge to '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'.

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

* 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
 - 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 merge to '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 cook in 'next'.
* la/diff-relative-config (2020-05-24) 1 commit
 - diff: add config option relative
 The commands in the "diff" family learned to honor "diff.relative"
 configuration variable.
 Will merge to '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
Elijah Newren· May 25, 2020, 14:55 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (May 2020, #08; Sun, 24)

On Sun, May 24, 2020 at 8:35 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
>
> 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 will be tagged soon, but most of the topics planned for
> it are already in 'master'.
>
> 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

Looks like the scissors docfix at https://lore.kernel.org/git/20200522142611.1217757-1-newren@gmail.com/ may have fallen through the cracks. It's not important for 2.27, but could that be picked up at least for pu?

Junio C Hamano· May 25, 2020, 16:22 UTC · re: Elijah Newren · lore

Re: What's cooking in git.git (May 2020, #08; Sun, 24)

Elijah Newren <newren@gmail.com> writes:
Show 19 quoted lines
> On Sun, May 24, 2020 at 8:35 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> 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 will be tagged soon, but most of the topics planned for
>> it are already in 'master'.
>>
>> 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
>
> Looks like the scissors docfix at
> https://lore.kernel.org/git/20200522142611.1217757-1-newren@gmail.com/
> may have fallen through the cracks.  It's not important for 2.27, but
> could that be picked up at least for pu?

Indeed, as I do not necessarily scan through messages all the way to the end, when it is clear that patches are discussed and polished by capable hands. I'd simply wait for the next round before jumping in in such a case, and shift the focus to other topics and/or tasks.

I haven't read the documentation patch yet, and I do not see anybody else reading it, either, so it probably is outside the scope for the upcoming release.

Thanks for pinging.
Todd Zullinger· May 25, 2020, 17:27 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (May 2020, #08; Sun, 24)

Hi,
Junio C Hamano wrote:
> Git 2.27-rc2 will be tagged soon, but most of the topics planned for
> it are already in 'master'.

There's a minor issue in the ss/faq-ignore topic which breaks the doc build on CentOS/ RHEL 6 that was mentioned by Son Luong Ngoc¹. The "." in the anchor text causes an issue for the older doc toolchain on these systems.

I included a simple patch for that in a reply². I haven't seen any discussion on it one way or another. At the risk of pestering, I thought I'd mention it in case it had just flown under everyone's radar during this busy time.

On one hand, the doc build toolchain on CentOS / RHEL 6 is old and those systems will be EOL at the end of November. So we might find it acceptable to stop supporting the doc build there.

On the other hand, the fix/workaround is quite trivial and nearly imperceptible to readers of the documentation. The problematic "." in ".gitiginore" only appears in the anchor link for HTML viewers or in the plain text for readers of the .txt file:

    [[files-in-.gitignore-are-tracked]]
vs.
    [[files-in-gitignore-are-tracked]]

I'm not sure there's enough value in keeping the "." in this case to justify breaking the doc build for users stuck on an old CentOS / RHEL 6 system.

I think the risk of applying the patch is sufficiently low that it would be worth including in 2.27.0. That is, unless there is a strong opinion that the "." is quite useful or that even low effort isn't worth taking to support such an old doc toolchain.

¹ https://lore.kernel.org/git/CAL3xRKdwOASiGys+7Uu_OA5kBPrTdAURfEw3UQ+rguTXT+C6JQ@mail.gmail.com/ ² https://lore.kernel.org/git/20200519045301.GY24220@pobox.com/

Thanks,
-- 
Todd
brian m. carlson· May 25, 2020, 17:53 UTC · re: Todd Zullinger · lore

Re: What's cooking in git.git (May 2020, #08; Sun, 24)

On 2020-05-25 at 17:27:08, Todd Zullinger wrote:
Show 42 quoted lines
> Hi,
> 
> Junio C Hamano wrote:
> > Git 2.27-rc2 will be tagged soon, but most of the topics planned for
> > it are already in 'master'.
> 
> There's a minor issue in the ss/faq-ignore topic which
> breaks the doc build on CentOS/ RHEL 6 that was mentioned by
> Son Luong Ngoc¹.  The "." in the anchor text causes an issue
> for the older doc toolchain on these systems.
> 
> I included a simple patch for that in a reply².  I haven't
> seen any discussion on it one way or another.  At the risk
> of pestering, I thought I'd mention it in case it had just
> flown under everyone's radar during this busy time.
> 
> On one hand, the doc build toolchain on CentOS / RHEL 6 is
> old and those systems will be EOL at the end of November.
> So we might find it acceptable to stop supporting the doc
> build there.
> 
> On the other hand, the fix/workaround is quite trivial and
> nearly imperceptible to readers of the documentation.  The
> problematic "." in ".gitiginore" only appears in the anchor
> link for HTML viewers or in the plain text for readers of
> the .txt file:
> 
>     [[files-in-.gitignore-are-tracked]]
> 
> vs.
> 
>     [[files-in-gitignore-are-tracked]]
> 
> I'm not sure there's enough value in keeping the "." in this
> case to justify breaking the doc build for users stuck on an
> old CentOS / RHEL 6 system.
> 
> I think the risk of applying the patch is sufficiently low
> that it would be worth including in 2.27.0.  That is, unless
> there is a strong opinion that the "." is quite useful or
> that even low effort isn't worth taking to support such an
> old doc toolchain.

I think since this is an anchor link it's just fine to change for compatibility. People are already used to slugs in fragments and elsewhere that don't include every possible component, and I think it would be better to produce more compatible ones over more precise ones. The burden of the change is very small, and the benefit is much greater.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Junio C Hamano· May 25, 2020, 18:13 UTC · re: brian m. carlson · lore

Re: What's cooking in git.git (May 2020, #08; Sun, 24)

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> I think since this is an anchor link it's just fine to change for
> compatibility.

Given that no other document in tree seems to point at the anchor, I think the patch is probably OK.

Thanks.
Todd Zullinger· May 26, 2020, 16:01 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (May 2020, #08; Sun, 24)

Junio C Hamano wrote:
Show 7 quoted lines
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
>> I think since this is an anchor link it's just fine to change for
>> compatibility.
> 
> Given that no other document in tree seems to point at the anchor, I
> think the patch is probably OK.
Excellent.  Thank you both for taking a look.
-- 
Todd

← back to recent threads