git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Corentin BOMPARD <corentin.bompard@etu.univ-lyon1.fr>
Cc: <git@vger.kernel.org>, <nathan.berbezier@etu.univ-lyon1.fr>,
	<pablo.chabanne@etu.univ-lyon1.fr>, <matthieu.moy@univ-lyon1.fr>
Subject: Re: [PATCH] doc: format pathnames and URLs as monospace
Date: Thu, 14 Feb 2019 12:44:13 -0800	[thread overview]
Message-ID: <xmqq4l9685ia.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20190214163043.7103-1-corentin.bompard@etu.univ-lyon1.fr> (Corentin BOMPARD's message of "Thu, 14 Feb 2019 17:30:43 +0100")

Corentin BOMPARD <corentin.bompard@etu.univ-lyon1.fr> writes:

> diff --git a/Documentation/config/checkout.txt b/Documentation/config/checkout.txt
> index c4118fa19..8ba92f274 100644
> --- a/Documentation/config/checkout.txt
> +++ b/Documentation/config/checkout.txt
> @@ -1,7 +1,7 @@
>  checkout.defaultRemote::
>  	When you run 'git checkout <something>' and only have one
>  	remote, it may implicitly fall back on checking out and
> -	tracking e.g. 'origin/<something>'. This stops working as soon
> +	tracking e.g. `origin/<something>`. This stops working as soon

Are you doing only pathnames and URLs, or are you also doing refnames?

I am not sure if "this is a pathname, or a URL or a refname, so it
must be typeset with monospace" is the direction we'd want to go in
in the first place.  One rule we tried to follow (but with minor
inconsistencies everywhere, apparently we are not doing a very good
job at) is "this is a string the user would literally type or see
when following this description, so it must be typeset with
monospace".

From that point of view, we'd want the `git checkout <something>` we
see in the introductory sentence of this paragraph also typeset in
mono.  In order to match (i.e. to make it clear that the <something>
part came from what the user typed), the change in this hunk your
patch makes does make sense.

> diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
> index f98b7c6ed..6643bc39f 100644
> --- a/Documentation/git-cvsserver.txt
> +++ b/Documentation/git-cvsserver.txt
> @@ -140,7 +140,7 @@ CVS_SERVER directly in CVSROOT like
>  ------
>  cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
>  ------
> -This has the advantage that it will be saved in your 'CVS/Root' files and
> +This has the advantage that it will be saved in your `CVS/Root` files and
>  you don't need to worry about always setting the correct environment
>  variable.  SSH users restricted to 'git-shell' don't need to override the default
>  with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean

I am using this hunk as just an example, but "this is what the user
literally sees or types" point-of-view, `CVS/Root` and `CVS_SERVER`
in the hunk fall into the same category.  They are both literals in
the sense that you cannot say "I do not like the words Root or
SERVER, so in my CVS repository I am using CVS/Leaf and CVS_HELPER
instead".

> @@ -179,7 +179,7 @@ allowing access over SSH.
>  ------
>  --
>  3. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command,
> -   automatically saving it in your 'CVS/Root' files, then you need to set them
> +   automatically saving it in your `CVS/Root` files, then you need to set them
>     explicitly in your environment.  CVSROOT should be set as per normal, but the
>     directory should point at the appropriate Git repo.  As above, for SSH clients
>     _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'.

Even if you are doing only pathnames and URLs, `git-shell` and
`git-cvsserver` would be candidates to be in monospace, as they are
names in $GIT_EXEC_PATH/.

> diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
> index 7a2375a55..bbc984235 100644
> --- a/Documentation/technical/pack-protocol.txt
> +++ b/Documentation/technical/pack-protocol.txt
> @@ -107,7 +107,7 @@ Initiating the upload-pack or receive-pack processes over SSH is
>  executing the binary on the server via SSH remote execution.
>  It is basically equivalent to running this:
>  
> -   $ ssh git.example.com "git-upload-pack '/project.git'"
> +   $ ssh git.example.com "git-upload-pack `/project.git`"
>  
>  For a server to support Git pushing and pulling for a given user over
>  SSH, that user needs to be able to execute one or both of those

I agree with Eric's comment.  If the user types `/project.git`, it
would give a funny result ;-).

  parent reply	other threads:[~2019-02-14 20:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-14 16:30 [PATCH] doc: format pathnames and URLs as monospace Corentin BOMPARD
2019-02-14 19:04 ` Eric Sunshine
2019-02-14 20:44 ` Junio C Hamano [this message]
2019-02-21  9:54   ` BOMPARD CORENTIN p1603631

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq4l9685ia.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=corentin.bompard@etu.univ-lyon1.fr \
    --cc=git@vger.kernel.org \
    --cc=matthieu.moy@univ-lyon1.fr \
    --cc=nathan.berbezier@etu.univ-lyon1.fr \
    --cc=pablo.chabanne@etu.univ-lyon1.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).