From: Junio C Hamano Date: Tue, 26 Mar 2024 20:20:16 GMT Subject: Re: [PATCH 4/4] doc: git-clone: apply new documentation guidelines Message-ID: In-Reply-To: Martin Ågren writes: >> +`git clone` [`--template=`{empty}____] >> + [`-l`] [`-s`] [`--no-hardlinks`] [`-q`] [`-n`] [`--bare`] [`--mirror`] >> + [`-o` __] [`-b` __] [`-u` __] [`--reference` __] >> + [`--dissociate`] [`--separate-git-dir` __] >> + [`--depth` __] [`--`[`no-`]`single-branch`] [`--no-tags`] >> + [`--recurse-submodules`[`=`{empty}____]] [`--`[`no-`]`shallow-submodules`] >> + [`--`[`no-`]`remote-submodules`] [`--jobs` __] [`--sparse`] [`--`[`no-`]`reject-shallow`] >> + [`--filter=`{empty}____] [`--also-filter-submodules`]] [`--`] __ >> + [__] > > Don't ask me why, but I need this on top (whitespace-damaged) > > - [`--depth` __] [`--`[`no-`]`single-branch`] [`--no-tags`] > - [`--recurse-submodules`[`=`{empty}____]] > [`--`[`no-`]`shallow-submodules`] > - [`--`[`no-`]`remote-submodules`] [`--jobs` __] > [`--sparse`] [`--`[`no-`]`reject-shallow`] > + [`--depth` __] [`--`[`no-`]{empty}`single-branch`] > [`--no-tags`] > + [`--recurse-submodules`[`=`{empty}____]] > [`--`[`no-`]{empty}`shallow-submodules`] > + [`--`[`no-`]{empty}`remote-submodules`] [`--jobs` __] > [`--sparse`] [`--`[`no-`]{empty}`reject-shallow`] > > i.e., some sprinkling of "{empty}", to keep each of these "[--[no-]" > from simply disappearing. This is with Asciidoctor 1.5.5, which is > admittedly starting to get old, but still ok as per our INSTALL > document. The original from Jean-Noël was already bad enough with all these {empty}, but now this is even worse. >> ---bare:: >> +`--bare`:: >> Make a 'bare' Git repository. That is, instead of >> creating __ and placing the administrative >> - files in `/.git`, make the __ >> + files in __`/.git`, make the __ > > This should be ____{empty}`/.git` The worst part is that I am not sure if there is a pattern easily understandable by document writers to help them decide where to sprinkle these {empty} mark-ups. Of course, they are visually very distracting and made our documentation that used to be perfectly readable in the source form to something much less pleasant to read. Can we make both the rendered output nicer while keeping the source still readable and easy to maintain? Thanks.