git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Rubén Justo" <rjusto@gmail.com>
Cc: Dragan Simic <dsimic@manjaro.org>,  git@vger.kernel.org
Subject: Re: [PATCH] branch: adjust documentation
Date: Thu, 29 Feb 2024 11:33:24 -0800	[thread overview]
Message-ID: <xmqqcysff4l7.fsf@gitster.g> (raw)
In-Reply-To: <cbaf17e7-37a6-4c2e-82ba-65fe41dd86b1@gmail.com> ("Rubén Justo"'s message of "Thu, 29 Feb 2024 19:56:05 +0100")

Rubén Justo <rjusto@gmail.com> writes:

> If we wisely choose the placeholder, perhaps we can write:
>
>     -m [<one>] <two>::
> 	Renames <one> (the current branch is used when not given) to
> 	a new name <two>, together with its reflog and configuration
> 	settings ...
>
> And if <one> is _good enough_ then "current branch is used when ..."
> should seem somewhat redundant.  So it could be possible to end up
> having something like:
>
>     -m [<one>] <two>::
> 	Renames <one> to a new name <two>, together with its reflog
> 	and configuration settings ...

If you use <the-current-branch-or-a-named-branch> or something
awkward like that as <one>, surely you can.  But I do not think we
want to go there.  And neither <branch-name> or <old-branch> would
remove the need for "if omitted then the current branch is used", I
am afraid, even though there may be a way to rephrase it more
concisely, e.g. "Rename the current branch (or <one> when given)..."

> Are we going to say "the current branch is used when ..." in the
> description for the other options too?  The description for "-c|-C",
> "--edit-description", "--unset-upstream", ...  Perhaps we are, and it
> will sound repetitive.

Do not forget that the objective of the larger-picture-revamping of
this page is to make the description of each option self-contained.
Similarity between -m's description and -c's description does not
count as being uselessly repetitive.

>> Even though the choice of words Rubén made in the patch under
>> discussion may work well in the current document structure.
>
> My patch is mainly about CodingGuideLines:
>
> 	If a placeholder has multiple words, they are separated by dashes:
> 	  <new-branch-name>
> 	  --template=<template-directory>

Yes, and that will be something we want to address _after_ we pick
what word or phrase would replace <one> or <two> in the above at the
conceptual level.  If we picked a single word, say "branch", we do
not even need to worry about dashes, and spell it just <branch>.  If
we did not pick "old branch", then we'd use "<old-branch>", but doing
such a conversion based on the current text is a wasted work, if we
end up using say "original branch" as the phrase, for example.

So if your patch is mainly about that part of the guideline, it is
addressing the documentation update in a wrong order, creating
possibly a wasted work.

  reply	other threads:[~2024-02-29 19:33 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 18:42 [PATCH] branch: rework the descriptions of rename and copy operations Dragan Simic
2024-02-15 19:28 ` Kristoffer Haugsbakk
2024-02-15 19:47   ` Dragan Simic
2024-02-15 20:41   ` Junio C Hamano
2024-02-15 21:00     ` Dragan Simic
2024-02-15 21:52 ` Rubén Justo
2024-02-15 22:13   ` Junio C Hamano
2024-02-15 23:34     ` Rubén Justo
2024-02-16  3:32       ` Dragan Simic
2024-02-17 14:58         ` Rubén Justo
2024-02-18 20:38           ` Dragan Simic
2024-02-19 19:49             ` Junio C Hamano
2024-02-19 19:55               ` Dragan Simic
2024-02-20 18:24                 ` Junio C Hamano
2024-02-20 19:12                   ` Rubén Justo
2024-02-20 19:49                     ` Dragan Simic
2024-02-20 20:25                     ` [PATCH] branch: adjust documentation Rubén Justo
2024-02-20 20:34                       ` Dragan Simic
2024-02-28  2:19                         ` Dragan Simic
2024-02-28 17:20                           ` Junio C Hamano
2024-02-28 17:24                             ` Junio C Hamano
2024-02-29  1:56                             ` Dragan Simic
2024-02-29 18:56                             ` Rubén Justo
2024-02-29 19:33                               ` Junio C Hamano [this message]
2024-02-29 20:02                                 ` Rubén Justo
2024-02-29 20:09                                   ` Dragan Simic
2024-03-02 16:18                                     ` Rubén Justo
2024-02-20 19:32                   ` [PATCH] branch: rework the descriptions of rename and copy operations Dragan Simic
2024-02-20 19:14             ` Rubén Justo
2024-02-20 19:56               ` Dragan Simic
2024-02-15 22:27   ` Dragan Simic
2024-02-15 23:38     ` Rubén Justo
2024-02-15 22:31 ` Kyle Lippincott
2024-02-15 22:38   ` Dragan Simic
2024-02-15 22:56     ` Kyle Lippincott
2024-02-15 23:09       ` Dragan Simic

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

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

  git send-email \
    --in-reply-to=xmqqcysff4l7.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=dsimic@manjaro.org \
    --cc=git@vger.kernel.org \
    --cc=rjusto@gmail.com \
    /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.
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 NNTP newsgroup(s).