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

Re: [PATCH v2 2/2] doc: git-worktree: Add side by side branch checkout example

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Oct 11, 2025, 05:17 UTC
Message-ID
<CAPig+cSNesf0UwS4=Bxe-Qn+G9y3YYPyOK+7y3q8QJk+o7jaVg@mail.gmail.com>
In-Reply-To
<0e11e6fb394ffa3a1286deea5a8ede5ba3e4bdf4.1760115862.git.msuchanek@suse.de>
On Fri, Oct 10, 2025 at 1:05 PM Michal Suchanek <msuchanek@suse.de> wrote:
> doc: git-worktree: Add side by side branch checkout example

Thanks for taking my suggestion[*] regarding a possible git-worktree documentation update and turning it into an actual patch. This is a reasonable beginning, but I think it needs more work.

To begin, the idea was to document that worktrees can be used with bare repositories, but neither the subject of this patch nor the prose added to the documentation itself mentions bare worktrees. Instead, they mention only "side by side branch checkouts", but I'm not even sure what that means. I certainly wouldn't think of "bare repository" when given the phrase "side by side branch checkouts", and I'm pretty sure that phrase is not part of the existing Git lexicon, whereas "bare repository" is, and is well known and well understood. So, I think both the commit message and the prose added to the documentation ought to mention "bare repository" instead.

Next, I think it is quite important that we spell out concretely in prose that worktrees can be used with a bare repository. It is not sufficient to merely infer it by giving an example, especially if the reader is primarily reading the git-worktree.txt introductory material which explains what worktrees are all about. So, for instance, we could expand the "The new worktree is called..." introductory paragraph to instead say something like this:

    This new worktree is called a "linked worktree" as opposed to the
    "main worktree" prepared by git-init(1) or git-clone(1). A
    repository has one main worktree (if it’s not a bare repository)
    and zero or more linked worktrees. Linked worktrees can also be
    used with a bare repository, in which case there is no main
    worktree but *only* linked worktrees (see EXAMPLES).

and also move the "When you are done with..." sentence from that paragraph down to the "If a working tree is deleted..." paragraph, which would become:

    When you are done with a linked worktree, remove it with `git
    worktree remove`. If a working tree is deleted without using `git
    worktree remove`, then its associated administrative files, which
    reside in the repository (see "DETAILS" below)...
Show 16 quoted lines
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> ---
> diff --git a/Documentation/git-worktree.adoc b/Documentation/git-worktree.adoc
> @@ -526,6 +526,16 @@ $ popd
>  $ git worktree remove ../temp
>  ------------
>
> +Side by side branch checkouts for a repository using multiple worktrees
> +
> +------------
> +mkdir some-repository
> +cd some-repository
> +git clone --bare gitforge@someforge.example.com:some-org/some-repository some-repository.git
> +git --git-dir=some-repository.git worktree add some-branch
> +git --git-dir=some-repository.git worktree add another-branch
> +------------
Several comments...

First, as mentioned above, rather than using the phrasing "side by side branch checkouts", let's talk about this as being an example of using worktrees with a bare repository.

Second, for consistency, let's follow the lead of the existing example in git-worktree.txt and show the "$" shell prompt preceding the commands. For instance:

    $ mkdir ...
    $ git clone ...

Third, the example seems overly complicated, especially with its use of `--git-dir`, which feels less discoverable (at least to me) than, say `-C`. What I have in mind is an example more like this:

    $ git clone --bare <repository-url> myproj.git
    $ git -C myproj.git worktree add feature-a
    $ git -C myproj.git worktree add feature-b

That should be more than sufficient to get people up and running with associating worktrees to a bare repository.

[*] https://lore.kernel.org/git/CAPig+cQgZijWi8VV1_QScKPhm9cqhQVvow4N-VH00R4oO1m2xA@mail.gmail.com/
Previous: Michal SuchanekNext: Junio C Hamano
Message 29 of 44 in “What is the reason behind not hiding git worktrees from git?”
  1. Jakub T. JankiewiczSep 27, 2025
  2. Junio C HamanoSep 27, 2025
  3. Michal SuchánekSep 27, 2025
  4. Jason ChoSep 27, 2025
  5. Jason ChoSep 27, 2025
  6. Michal SuchánekSep 30, 2025
  7. Junio C HamanoSep 30, 2025
  8. Michal SuchánekNov 19, 2025
  9. Michal SuchánekSep 30, 2025
  10. Ben KnobleOct 1, 2025
  11. Junio C HamanoOct 1, 2025
  12. Sergey OrganovOct 1, 2025
  13. Junio C HamanoOct 1, 2025
  14. Jakub T. JankiewiczOct 1, 2025
  15. Junio C HamanoOct 1, 2025
  16. Eric SunshineOct 1, 2025
  17. Junio C HamanoOct 1, 2025
  18. Michal SuchánekOct 2, 2025
  19. Junio C HamanoOct 2, 2025
  20. 1/2 doc: git-worktree: Link to examplesMichal Suchanek, Oct 2, 2025
  21. Kristoffer HaugsbakkOct 2, 2025
  22. Junio C HamanoOct 2, 2025
  23. Michal SuchánekOct 2, 2025
  24. Jean-Noël AVILAOct 5, 2025
  25. Michal SuchánekOct 10, 2025
  26. 1/2 doc: git-worktree: Link to examplesMichal Suchanek, Oct 10, 2025
  27. Eric SunshineOct 11, 2025
  28. 2/2 doc: git-worktree: Add side by side branch checkout exampleMichal Suchanek, Oct 10, 2025
  29. Eric SunshineOct 11, 2025
  30. Junio C HamanoOct 23, 2025
  31. Michal SuchánekOct 24, 2025
  32. Eric SunshineOct 24, 2025
  33. Michal SuchánekNov 18, 2025
  34. Eric SunshineNov 19, 2025
  35. Junio C HamanoJan 20, 2026
  36. 2/2 doc: git-worktree: Add side by side branch checkout exampleMichal Suchanek, Oct 2, 2025
  37. Kristoffer HaugsbakkOct 2, 2025
  38. Michal SuchánekOct 2, 2025
  39. Junio C HamanoOct 2, 2025
  40. Junio C HamanoOct 2, 2025
  41. Michal SuchánekOct 2, 2025
  42. Johannes SchindelinNov 17, 2025
  43. Junio C HamanoNov 17, 2025
  44. Ben KnobleOct 2, 2025

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.