git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Julia Evans via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  "D. Ben Knoble" <ben.knoble@gmail.com>,
	 Julia Evans <julia@jvns.ca>
Subject: Re: [PATCH v2 3/5] doc: git-checkout: don't use "reset"
Date: Fri, 29 Aug 2025 09:22:23 -0700	[thread overview]
Message-ID: <xmqqh5xqnlmo.fsf@gitster.g> (raw)
In-Reply-To: <360051d2a656727ca42d489de81ffec9b23a6386.1756467934.git.gitgitgadget@gmail.com> (Julia Evans via GitGitGadget's message of "Fri, 29 Aug 2025 11:45:32 +0000")

"Julia Evans via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Julia Evans <julia@jvns.ca>
>
> Many Git users don't know what the term "reset" means. Resolve this by:

Even though it is the name of one of the most often used commands?
And yet a separate step in this series made the claim that everybody
knows what "switch" means because it is the name of another command?

I think the source of the problem is not that they "don't know what
the term means" at all.  Isn't the real problem that the use of the
verb in the original sentence you are correcting in this patch is
vague and does not say what the branch is reset *to*?

> - Expanding it into its definition, in one case

    The description says "-B <branch>" resets the branch if it
    exists, but does not say what it resets to.  Rephrase to clarify
    that it is made to point at the specified commit.

or something?

> - Giving a simpler but still accurate explanation ("the branch will not
>   be created or modified"), in the other case

By the way this kind of use of bulleted list in a proposed log
message I do not mind all that much.  What I reacted to was a list
without the introducing text (in the case of this patch, "resolve
this by doing these things:").
>
> Signed-off-by: Julia Evans <julia@jvns.ca>
> ---
>  Documentation/git-checkout.adoc | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/git-checkout.adoc b/Documentation/git-checkout.adoc
> index 4de3ac6680..e4614674f0 100644
> --- a/Documentation/git-checkout.adoc
> +++ b/Documentation/git-checkout.adoc
> @@ -54,18 +54,17 @@ to print out the tracking information for the current branch.
>  	`--track` without `-b` implies branch creation; see the
>  	description of `--track` below.
>  +
> -If `-B` is given, _<new-branch>_ is created if it doesn't exist; otherwise, it
> -is reset. This is the transactional equivalent of
> +If `-B` is given, _<new-branch>_ is created if it doesn't exist;
> +otherwise `<new-branch>` is forced to point at the commit. ...

Good.

> ... This is the
> +transactional equivalent of
>  +
>  ------------
>  $ git branch -f <branch> [<start-point>]
>  $ git checkout <branch>
>  ------------
>  +
> -that is to say, the branch is not reset/created unless "git checkout" is
> -successful (e.g., when the branch is in use in another worktree, not
> -just the current branch stays the same, but the branch is not reset to
> -the start-point, either).
> +that is, the branch will not be created or modified unless
> +`git checkout` is successful.
>  
>  `git checkout --detach [<branch>]`::
>  `git checkout [--detach] <commit>`::

This is in response to "transactional equivalent".  I've always felt
that there is no need to say "transactional" in this at all.  IOW, I
wouldn't have minded if we rewrote this more heavily.

When you have to clarify with things like "that is", "what this
means is", etc., after some text, I've often found that the result
becomes crispier and more clear if we removed fuzzy text that needed
such clarification and rewrite the sentence using elements form only
the clarifying text.

    If `-B` is given, _<new-branch>_ is created if it doesn't exist,
    otherwise, it is made to point at the given commit.  And the
    branch is made the current branch.
    +
    Creation of the new branch or reseting of the existing branch to
    point at the commit happens only if the resulting branch can be
    successfully checked out.  Oterwise branch creation is not done
    and the exiting branch is left as-is.

or something?  I dunno.


  reply	other threads:[~2025-08-29 16:22 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-25 19:08 [PATCH 0/5] doc: git-checkout: clarify DESCRIPTION section Julia Evans via GitGitGadget
2025-08-25 19:08 ` [PATCH 1/5] doc: git-checkout: clarify intro Julia Evans via GitGitGadget
2025-08-26 18:46   ` Junio C Hamano
2025-08-26 18:51     ` Junio C Hamano
2025-08-26 20:56     ` Julia Evans
2025-08-28 14:00   ` D. Ben Knoble
2025-08-28 22:34     ` Julia Evans
2025-08-28 23:44       ` Junio C Hamano
2025-08-29 13:39         ` D. Ben Knoble
2025-08-29 21:00     ` Junio C Hamano
2025-09-03 23:48       ` D. Ben Knoble
2025-08-25 19:08 ` [PATCH 2/5] doc: git-checkout: clarify `git checkout <branch>` Julia Evans via GitGitGadget
2025-08-26 21:38   ` Junio C Hamano
2025-08-28 12:11     ` Julia Evans
2025-08-28 15:45       ` Junio C Hamano
2025-08-28 18:24         ` Julia Evans
2025-08-25 19:08 ` [PATCH 3/5] doc: git-checkout: don't use "reset" Julia Evans via GitGitGadget
2025-08-25 19:08 ` [PATCH 4/5] doc: git-checkout: deduplicate --detach explanation Julia Evans via GitGitGadget
2025-08-25 19:08 ` [PATCH 5/5] doc: git-checkout: clarify restoring files section Julia Evans via GitGitGadget
2025-08-26 22:43   ` Junio C Hamano
2025-08-28 13:26     ` Julia Evans
2025-08-28 19:08   ` D. Ben Knoble
2025-08-28 19:59     ` Julia Evans
2025-08-28 20:38       ` Junio C Hamano
2025-08-29 13:48       ` D. Ben Knoble
2025-08-29 11:45 ` [PATCH v2 0/5] doc: git-checkout: clarify DESCRIPTION section Julia Evans via GitGitGadget
2025-08-29 11:45   ` [PATCH v2 1/5] doc: git-checkout: clarify intro Julia Evans via GitGitGadget
2025-08-29 15:58     ` Junio C Hamano
2025-09-02 17:14       ` Julia Evans
2025-08-29 11:45   ` [PATCH v2 2/5] doc: git-checkout: clarify `git checkout <branch>` Julia Evans via GitGitGadget
2025-08-29 16:03     ` Junio C Hamano
2025-09-02 17:16       ` Julia Evans
2025-08-29 11:45   ` [PATCH v2 3/5] doc: git-checkout: don't use "reset" Julia Evans via GitGitGadget
2025-08-29 16:22     ` Junio C Hamano [this message]
2025-09-01 14:28       ` Julia Evans
2025-09-02 16:10         ` Junio C Hamano
2025-08-29 11:45   ` [PATCH v2 4/5] doc: git-checkout: deduplicate --detach explanation Julia Evans via GitGitGadget
2025-08-29 11:45   ` [PATCH v2 5/5] doc: git-checkout: clarify restoring files section Julia Evans via GitGitGadget
2025-09-03 16:49   ` [PATCH v3 0/6] doc: git-checkout: clarify DESCRIPTION section Julia Evans via GitGitGadget
2025-09-03 16:49     ` [PATCH v3 1/6] doc: git-checkout: clarify intro Julia Evans via GitGitGadget
2025-09-03 16:49     ` [PATCH v3 2/6] doc: git-checkout: clarify `git checkout <branch>` Julia Evans via GitGitGadget
2025-09-03 16:49     ` [PATCH v3 3/6] doc: git-checkout: clarify `-b` and `-B` Julia Evans via GitGitGadget
2025-09-03 16:50     ` [PATCH v3 4/6] doc: git-checkout: deduplicate --detach explanation Julia Evans via GitGitGadget
2025-09-03 16:50     ` [PATCH v3 5/6] doc: git-checkout: split up restoring files section Julia Evans via GitGitGadget
2025-09-03 16:50     ` [PATCH v3 6/6] doc: git-checkout: clarify " Julia Evans via GitGitGadget
2025-09-03 21:29       ` Junio C Hamano
2025-09-03 21:09     ` [PATCH v3 0/6] doc: git-checkout: clarify DESCRIPTION section Junio C Hamano
2025-09-03 21:28       ` Julia Evans
2025-09-10 19:14     ` [PATCH v4 0/7] " Julia Evans via GitGitGadget
2025-09-10 19:14       ` [PATCH v4 1/7] doc: git-checkout: clarify intro sentence Julia Evans via GitGitGadget
2025-09-10 19:14       ` [PATCH v4 2/7] doc: git-checkout: clarify ARGUMENT DISAMBIGUATION Julia Evans via GitGitGadget
2025-09-10 19:14       ` [PATCH v4 3/7] doc: git-checkout: clarify `git checkout <branch>` Julia Evans via GitGitGadget
2025-09-10 19:14       ` [PATCH v4 4/7] doc: git-checkout: clarify `-b` and `-B` Julia Evans via GitGitGadget
2025-09-29 18:07         ` Kristoffer Haugsbakk
2025-10-02 18:37           ` [PATCH] doc: git-checkout: fix placeholder markup kristofferhaugsbakk
2025-10-16 22:11             ` [PATCH resend] " kristofferhaugsbakk
2025-10-17 13:56               ` Julia Evans
2025-10-17 15:50               ` [PATCH v2] " kristofferhaugsbakk
2025-09-10 19:14       ` [PATCH v4 5/7] doc: git-checkout: deduplicate --detach explanation Julia Evans via GitGitGadget
2025-09-10 19:14       ` [PATCH v4 6/7] doc: git-checkout: split up restoring files section Julia Evans via GitGitGadget
2025-09-10 19:14       ` [PATCH v4 7/7] doc: git-checkout: clarify " Julia Evans via GitGitGadget
2025-09-11 13:01       ` [PATCH v4 0/7] doc: git-checkout: clarify DESCRIPTION section Ben Knoble
2025-09-12 14:05         ` Julia Evans
2025-09-12 14:26           ` Kristoffer Haugsbakk
2025-09-15 23:22             ` Junio C Hamano
2025-09-16  6:41               ` Kristoffer Haugsbakk
2025-09-12 16:23           ` Junio C Hamano
2025-09-17 18:38       ` Junio C Hamano

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=xmqqh5xqnlmo.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ben.knoble@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=julia@jvns.ca \
    /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).