git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Dragan Simic <dsimic@manjaro.org>
Cc: "Rubén Justo" <rjusto@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] branch: rework the descriptions of rename and copy operations
Date: Tue, 20 Feb 2024 10:24:25 -0800	[thread overview]
Message-ID: <xmqqttm3ouxy.fsf@gitster.g> (raw)
In-Reply-To: <35738a93f5cbace5b3235ce614b7afbf@manjaro.org> (Dragan Simic's message of "Mon, 19 Feb 2024 20:55:33 +0100")

Dragan Simic <dsimic@manjaro.org> writes:

>> My advice would be to stick to <old> vs <new> that contrasts well.
>
> I appreciate the directness and honesty.  How about using "<oldbranch>"
> and "<newbranch>" instead, which, although more wordy, would be more
> consistent with "<branch>" that's used in a number of other places?

I have slight aversion to non-words like "oldbranch" (not
"old-branch"), but not that much.

Quite honestly, in a document whose primary topic is "branch", I
doubt that repeating "branch" all over the place would be the
consistency we should be aiming for in the first place, when it is
clear from the context that we are talking about branches.

The updates we are making to Documentation/git-branch.txt that (1)
slims wordy description of different modes in the DESCRIPTION
section, (2) make option description of "-m" mention what
argument(s) the option takes, and (3) rmove standalone <newbranch>
and <oldbranch> description are all about making the necessary piece
of information easier to find in one place (namely, the option
description where "-m [<one branch name>] [<the other branch name>]"
is described) without having to jump around all over in the
documentation, so in that sense, I would think the way to go is to
aim for brevity that takes advantage of the local context.


  reply	other threads:[~2024-02-20 18:24 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 [this message]
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
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=xmqqttm3ouxy.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).