[pull] master from git:master#120
Merged
pull[bot] merged 20 commits intoturkdevops:masterfrom Oct 25, 2025
Merged
Conversation
c348192 (t1016: clean up style, 2024-10-22) fixed a coding style violation that has an extra space between redirection operator ">" and the redirection target, but at the same time, replaced the use of "git config" to set a configuration variable to be used by the remainder of tests with "test_config". The pattern employed here is that the first set-up test prepares the environment to be used by subsequent tests, which then use the settings left by this set-up test to perform their tasks. Using test_config in the first set-up test means the config setting made by the set-up test is reverted at the end of the first set-up test, which totally misses the point. Go back to use "git config" to fix this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both asciidoc and ascidoctor issue warnings about 'list item index:
expected n got n-1' for n=1->9 on lines 13, 15, 17, 20, 23, 25, 29,
31 and 33. In asciidoc, numbered lists must start at one, whereas this
file has a list starting at zero. Also, asciidoc and asciidoctor warn
about 'section title out of sequence: expected level 1, got level 2'
on line 38. (asciidoc only complains about the first instance of this,
while asciidoctor complains about them all, on lines 94, 141, 142,
184, 185, 257, 288, 289, 290, 397, 424, 485, 486 and 487). These
warnings stem from the section titles not being correctly nested within
a document/chapter title.
In order to address the first set of warnings, simply renumber the list
from one to nine, rather than zero to eight. This also requires altering
the text which refers to the section numbers, including other section
titles.
In order to address the second set of warnings, change the section title
syntax from '=== title ===' to '== title ==', effectively reducing the
nesting level of the title by one. Also, some of the titles are given
over multiple lines (they are very long), with an title '===' prefix
on each line. This leads to them being treated as separate sections
with no body text (as you can see from the line numbers given for the
asciidoctor warnings, above). So, for these titles, turn them into a
single (long) line of text.
In addition to the warnings, address some other formatting issues:
- the ascii branch diagrams didn't format correctly on asciidoctor
so include them in a literal block.
- several blocks of text were intended to be formatted 'as is' but
were not included in a literal block.
- in section 8, format the (A)->(D) in the text description as a
literal with `` marks, since (C) is rendered as a copyright
symbol in html otherwise.
- in section 9, a sub-list of two items is not formatted as such.
change the '*' introducer to '**' to correct the sub-list format.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both asciidoc and asciidoctor issue warnings about 'list item index:
expected n got n-1' for n=1->7 on lines 928, 931, 951, 974, 980, 1033
and 1049. In asciidoc, numbered lists must start at one, whereas this
file has a list starting at zero. Also, asciidoc and asciidoctor warn
about 'section title out of sequence: expected level 1, got level 2'
on line 17. (asciidoc only complains about the first instance of this,
while asciidoctor complains about them all, on lines 95, 258, 303, 316,
545, 612, 752, 824, 895, 923 and 1053). These warnings stem from the
section titles not being correctly nested within a document/chapter
title.
In order to address the first set of warnings, simply renumber the list
from one to seven, rather than zero to six. Fortunately, this does not
require altering additional text, since the enumeration of 'Known Bugs'
is not referred to anywhere else in the document.
In order to address the second set of warnings, change the section title
syntax from '=== title ===' to '== title ==', effectively reducing the
nesting level of the title by one. Also, some apparent (sub-)titles are
not marked up with sub-title syntax, so add some '=== ' prefix(s) to the
relevant headings.
In addition to the warnings, address some other formatting issues:
- the use of heavily nested unordered lists is not reflected in the
output (making the file totally unreadable) because each level of
nesting requires a different syntax. (i.e. replace '*' with '**'
for the second level, '*' with '***' for the third level, etc.)
- make use of literal blocks and manual indentation to get asciidoc
and asciidoctor to display even remotely similar output.
- make use of labelled lists, in some places, to get a similar looking
output to the input, for both asciidoc and asciidoctor.
- replace the trailing space in: `git grep ${SEARCH_TERM} OLDREV `
otherwise the entire line in which that appears is removed from
the output.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The formatting markup syntax used in this document (markdown?) is not
interpreted correctly by asciidoc or asciidoctor. The main problem is
the use of a '## ' prefix markup for some sub-headings, along with the
use of '```' code markup and some missing literal blocks.
In order to improve the (html) document formatting:
- replace the '## ' prefix sub-title syntax with the '~~' underlining
syntax for the relevant sub-headings.
- replace the '```' code markup, which causes asciidoc(tor) to simply
remove the marked up text, with a literal block '----' markup.
- the second ascii diagram, in the 'Merging commit-graph files'
section, is not rendered correctly by asciidoctor (asciidoc is fine)
so enclose it in a '....' block.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 5040f9f ("doc: add technical design doc for large object promisors", 2025-02-18) added the large object promisors document as a technical document (with a '.txt' extension). The merge commit 2c6fd30 ("Merge branch 'cc/lop-remote'", 2025-03-05) seems to have renamed the file with an '.adoc' extension. Despite the '.adoc' extension, this document was not being formatted by asciidoc(tor) as part of the docs build. In order to do so, add the document to the make and meson build files. Having added the document to the build, asciidoc and asciidoctor find (slightly different) problems with the syntax of the input document. The first set of warnings (only issued by asciidoc) relate to some 'section title out of sequence: expected level 3, got level 4'. This document uses 'setext' style of section headers, using a series of underline characters, where the character used denotes the level of the title. From document title to level 5 (see [1]), these characters are =, -, ~, ^, +. This does not seem to fit the error message, which implies that those characters denote levels 0 -> 4. Replacing the headings underlined with '+' by the '^' character eliminates these warnings. The second set of warnings (only issued by asciidoctor) relate to some headings which seem to use both arabic and roman numerals as part of a single 'list' sequence. This elicited either 'unterminated listing block' or (for example) 'list item index: expected I, got II' warnings. In order not to mix arabic and roman numerals, remove the numeral from the '0) Non goals' heading. Similarly, the remaining roman numeral entries had the ')' removed and turned into regular headings with I, II, III ... at the beginning. [1] https://asciidoctor.org/docs/asciidoc-recommended-practices/ Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running "git status -z --short", the marker on modified index entries (e.g., "M") is colorized, but the "??" marker for untracked entries is not. Let's fix the "??" entries to show color here. At first glance you might think that neither should be colorized, as usually one would use "-z" to get machine-readable output. But this is a tricky and unusual case. We have two output formats, "--short" and "--porcelain" which are substantially similar, but differ in that "--short" is for humans who want something short and "--porcelain" is for machines. And "-z" by itself, without any other output option, does default to "--porcelain", so "git status -z" will not colorize anything. But if you explicitly ask for "-z" and "--short" together, then that is asking for the human-readable output, but separated by NULs. This is unlikely to be useful directly, but could for example be used if the output will be shown to a human outside of the terminal. At any rate, the current behavior is clearly wrong (since we colorize some things but not others), and I think colorizing everything is the least-surprising thing we can do here. Reported-by: Langbart <Langbart@protonmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, the MSYS layer translates absolute path names generated by a shell script from the POSIX style /c/dir/file to the Windows style C:/dir/file form that is understood by git.exe. This happens only when the absolute path stands on its own as a program argument or a value of an environment variable. The earlier commits 749d6d1 (config: values of pathname type can be prefixed with :(optional), 2025-09-28) and ccfcaf3 (parseopt: values of pathname type can be prefixed with :(optional), 2025-09-28) added test cases where ":(optional)" is inserted before an absolute path. $PWD is used to construct the absolute paths, which gives the POSIX form, and the result is ":(optional)/c/dir/template". Such command line arguments are no longer recognized as absolute paths and do not undergo translation. Existing test cases that expect that the specified file does not exist are not incorrect (after all, git.exe will not find /c/dir/template). Yet, they are conceptually incorrect. That the use of $PWD is erroneous is revealed by a test case that expects that the optional file exists. Since no such test case is present, add one. Use "$(pwd)" to generate the absolute paths, so that the command line arguments become ":(optional)C:/dir/template". Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update these Makefiles to be in line with other Makefiles from contrib such as for contacts or subtree by making the following changes: * Make the default settings after including config.mak.autogen and config.mak. * Add the missing $(CPPFLAGS) to the compiler command as well as the missing $(CFLAGS) to the linker command. * Use a pattern rule for compilation instead of a dedicated rule for each compile unit. * Get rid of $(MAIN), $(SRCS) and $(OBJS) and simply use their values such as git-credential-libsecret and git-credential-libsecret.o. * Strip @ from $(RM) to let the clean target rule be verbose. * Define .PHONY for all special targets (all, clean). Signed-off-by: Thomas Uhle <thomas.uhle@mailbox.tu-dresden.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unicode 17 is out. Update the unicode with table. https://blog.unicode.org/2025/09/unicode-170-release-announcement.html Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Show option P in the prompt and explain it properly on a dedicated line in online help and documentation. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In t7528 we spawn an SSH agent to verify that we can sign a commit via
it. This test has started to fail on some machines:
+++ ssh-agent
unix_listener_tmp: path "/home/pks/Development/git/build/test-output/trash directory.t7528-signed-commit-ssh/.ssh/agent/s.UTulegefEg.agent.UrPHumMXPq" too long for Unix domain socket
main: Couldn't prepare agent socket
As it turns out this is caused by a change in OpenSSH 10.1 [1]:
* ssh-agent(1), sshd(8): move agent listener sockets from /tmp to
under ~/.ssh/agent for both ssh-agent(1) and forwarded sockets
in sshd(8).
Instead of creating the socket in "/tmp", OpenSSH now creates the socket
in our home directory. And as the home directory gets modified to be
located in our test output directory we end up with paths that are
somewhat long. But Linux has a rather short limit of 108 characters for
socket paths, and other systems have even lower limits, so it is very
easy now to exceed the limit and run into the above error.
Work around the issue by using `ssh-agent -T`, which instructs it to
use the old behaviour and create the socket in "/tmp" again. This switch
has only been introduced with 10.1 though, so for older versions we have
to fall back to not using it. That's fine though, as older versions know
to put the socket into "/tmp" already.
An alternative approach would be to abbreviate the socket name itself so
that we create it as e.g. "sshsock" in the trash directory. But taking
the above example we'd still end up with a path that is 91 characters
long. So we wouldn't really have a lot of headroom, and it is quite
likely that some developers would see the issue on their machines.
[1]: https://www.openssh.com/txt/release-10.1
Reported-by: Xi Ruoyao <xry111@xry111.site>
Suggested-by: brian m. carlson <sandals@crustytoothpaste.net>
Helped-by: Jeff King <peff@peff.net>
Helped-by: Lauri Tirkkonen <lauri@hacktheplanet.fi>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation mark-up fixes. * rj/doc-technical-fixes: doc: add large-object-promisors.adoc to the docs build doc: commit-graph.adoc: fix up some formatting doc: sparse-checkout.adoc: fix asciidoc warnings doc: remembering-renames.adoc: fix asciidoc warnings
Test fix. * js/t7500-pwd-windows-fix: t7500: fix tests with absolute path following ":(optional)" on Windows
The "--short" option of "git status" that meant output for humans and "-z" option to show NUL delimited output format did not mix well, and colored some but not all things. The command has been updated to color all elements consistently in such a case. * jk/status-z-short-fix: status: make coloring of "-z --short" consistent
Build procedure for a few credential helpers (in contrib/) have been updated. * tu/credential-makefile-updates: contrib/credential: harmonize Makefiles
Unicode width table update. * tb/unicode-width-table-17: unicode: update the width tables to Unicode 17
GPG signing test set-up has been broken for a year, which has been corrected. * jc/t1016-setup-fix: t1016: make sure to use specified GPG
Show 'P'ipe command in "git add -p". * rs/add-patch-document-p-for-pager: add-patch: fully document option P
Recent OpenSSH creates the Unix domain socket to communicate with ssh-agent under $HOME instead of /tmp, which causes our test to fail doe to overly long pathname in our test environment, which has been worked around by using "ssh-agent -T". * ps/t7528-ssh-agent-uds-workaround: t7528: work around ETOOMANY in OpenSSH 10.1 and newer
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )