git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] branch: adjust documentation

From
Rubén Justo <rjusto@gmail.com>
Date
Feb 29, 2024, 18:56 UTC
Message-ID
<cbaf17e7-37a6-4c2e-82ba-65fe41dd86b1@gmail.com>
In-Reply-To
<xmqqttlsld4t.fsf@gitster.g>
On Wed, Feb 28, 2024 at 09:20:02 -0800, Junio C Hamano wrote:
Show 15 quoted lines
> The current description section talks about option and its arguments
> without showing the syntax, making it unnecessarily extra verbose.
> For example, we see something like this:
> 
>     With a `-m` or `-M` option, <oldbranch> will be renamed to
>     <newbranch>.  If <oldbranch> had a corresponding reflog, it is
>     renamed to match ...
> 
> But in the final shape of the documentation, I would like to see the
> description section not talk about these arguments, and would read
> more like
> 
>     When given `-m` or `-M` options, the command renames an existing
>     branch to a different name.
> 
Good.
Show 9 quoted lines
> among short descriptions made at the conceptual level on other modes
> like "listing" mode, "delete" mode, etc. [*3*] 
> 
> And the option description would become something like [*]:
> 
>     -m [<one>] <two>::
> 	Renames the branch <one> (the current branch is used when
> 	not given) to a new name <two>, together with its reflog and
> 	configuration settings for the branch. ...
> Now in such a context, <one> and <two> placeholders having actually
> the word "branch" in it would sound redundant and awkward to read,
Indeed.
But I'm on the fence.  Do we have to use "Renames the branch <one>"?
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 ...

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. However, even if we do, with the _good enough_ placeholder the user will be able to fill the gaps we might leave in the documentation, like the one that presumably has bring us here: pull.1613.git.git.1701303891791.gitgitgadget@gmail.com.

And finally; Can't <one> and <two> be consistent with other bits we have in the documentation like the descriptions of "git switch <one>", "git checkout -b <two>" or "git init -b <three>"?

After the revamp, I'll be less happy (but happy :-) nonetheless) if we end up having a SYNOPSIS similar to the one we have today:

 - Documentation/git-branch.txt:
      'git branch' (-c | -C) [<one>] <two>
      'git branch' (-d | -D) [-r] <three>...
      'git branch' --edit-description [<three>]
It seems to me to be made up of disconnected pieces.
And for reference:
 - Documentation/git-switch.txt:
      'git switch' [<options>] [--no-guess] <four>
      'git switch' [<options>] --orphan <five>
 - Documentation/git-init.txt:
      'git init' [--initial-branch=<six>]

My apologies if I'm pushing too hard on this and being reiterative in my messages in this series. My intention has been to explore the use we want of the placeholders. Of course, this is not at odds with my sympathy for the vision proposed. I agree on the direction.

> 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>
Previous: Dragan SimicNext: Junio C Hamano
Message 23 of 36 in “branch: rework the descriptions of rename and copy operations”
  1. branch: rework the descriptions of rename and copy operationsDragan Simic, Feb 15, 2024
  2. Kristoffer HaugsbakkFeb 15, 2024
  3. Dragan SimicFeb 15, 2024
  4. Junio C HamanoFeb 15, 2024
  5. Dragan SimicFeb 15, 2024
  6. Rubén JustoFeb 15, 2024
  7. Junio C HamanoFeb 15, 2024
  8. Rubén JustoFeb 15, 2024
  9. Dragan SimicFeb 16, 2024
  10. Rubén JustoFeb 17, 2024
  11. Dragan SimicFeb 18, 2024
  12. Junio C HamanoFeb 19, 2024
  13. Dragan SimicFeb 19, 2024
  14. Junio C HamanoFeb 20, 2024
  15. Rubén JustoFeb 20, 2024
  16. Dragan SimicFeb 20, 2024
  17. branch: adjust documentationRubén Justo, Feb 20, 2024
  18. Dragan SimicFeb 20, 2024
  19. Dragan SimicFeb 28, 2024
  20. Junio C HamanoFeb 28, 2024
  21. Junio C HamanoFeb 28, 2024
  22. Dragan SimicFeb 29, 2024
  23. Rubén JustoFeb 29, 2024
  24. Junio C HamanoFeb 29, 2024
  25. Rubén JustoFeb 29, 2024
  26. Dragan SimicFeb 29, 2024
  27. Rubén JustoMar 2, 2024
  28. Dragan SimicFeb 20, 2024
  29. Rubén JustoFeb 20, 2024
  30. Dragan SimicFeb 20, 2024
  31. Dragan SimicFeb 15, 2024
  32. Rubén JustoFeb 15, 2024
  33. Kyle LippincottFeb 15, 2024
  34. Dragan SimicFeb 15, 2024
  35. Kyle LippincottFeb 15, 2024
  36. Dragan SimicFeb 15, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.