aboutsummaryrefslogtreecommitdiff
path: root/Documentation/technical/sparse-checkout.adoc
AgeCommit message (Collapse)Author
2025-10-16doc: sparse-checkout.adoc: fix asciidoc warningsRamsay Jones
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>
2025-06-25Merge branch 'jc/you-still-use-whatchanged'Junio C Hamano
"git whatchanged" that is longer to type than "git log --raw" which is its modern rough equivalent has outlived its usefulness more than 10 years ago. Plan to deprecate and remove it. * jc/you-still-use-whatchanged: whatschanged: list it in BreakingChanges document whatchanged: remove when built with WITH_BREAKING_CHANGES whatchanged: require --i-still-use-this tests: prepare for a world without whatchanged doc: prepare for a world without whatchanged you-still-use-that??: help deprecating commands for removal
2025-06-02Merge branch 'wk/sparse-checkout-doc-fix'Junio C Hamano
Doc update. * wk/sparse-checkout-doc-fix: doc: sparse-checkout: use consistent inline list style
2025-05-30doc: sparse-checkout: use consistent inline list styleWonuk Kim
Fix this inline list to use a single style, namely numeric, instead of `(1)` followed by `(b)`. Signed-off-by: Wonuk Kim <kimww0306@gmail.com> Acked-by: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-12whatchanged: remove when built with WITH_BREAKING_CHANGESJunio C Hamano
As we made "git whatchanged" require "--i-still-use-this" and asked the users to report if they still want to use it, the logical next step is to allow us build Git without "whatchanged" to prepare for its eventual removal. If we were to follow the pattern established in 8ccc75c2 (remote: announce removal of "branches/" and "remotes/", 2025-01-22), we can do this together with the documentation update to officially list that the command will be removed in the BreakingChanges document, but let's just keep the changes separate just in case we want to proceed a bit slower. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-08merge-recursive.[ch]: thoroughly debug theseElijah Newren
As a wise man once told me, "Deleted code is debugged code!" So, move the functions that are shared between merge-recursive and merge-ort from the former to the latter, and then debug the remainder of merge-recursive.[ch]. Joking aside, merge-ort was always intended to replace merge-recursive. It has numerous advantages over merge-recursive (operates much faster, can operate without a worktree or index, and fixes a number of known bugs and suboptimal merges). Since we have now replaced all callers of merge-recursive with equivalent functions from merge-ort, move the shared functions from the former to the latter, and delete the remainder of merge-recursive.[ch]. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-01-21doc: use .adoc extension for AsciiDoc filesbrian m. carlson
We presently use the ".txt" extension for our AsciiDoc files. While not wrong, most editors do not associate this extension with AsciiDoc, meaning that contributors don't get automatic editor functionality that could be useful, such as syntax highlighting and prose linting. It is much more common to use the ".adoc" extension for AsciiDoc files, since this helps editors automatically detect files and also allows various forges to provide rich (HTML-like) rendering. Let's do that here, renaming all of the files and updating the includes where relevant. Adjust the various build scripts and makefiles to use the new extension as well. Note that this should not result in any user-visible changes to the documentation. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>