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

Re: [PATCH] Documentation/git-worktree: use working tree for trees on the file system

From
Duy Nguyen <pclouds@gmail.com>
Date
Mar 25, 2017, 12:05 UTC
Message-ID
<CACsJy8D-+uO2GabNGLcTvfs7k8NrG1x200j3nOx11u8uUdzZVw@mail.gmail.com>
In-Reply-To
<xmqqvar2ska7.fsf@gitster.mtv.corp.google.com>
On Tue, Mar 21, 2017 at 10:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 35 quoted lines
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Tue, Mar 21, 2017 at 1:50 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>> Junio C Hamano wrote:
>>>> Stefan Beller <sbeller@google.com> writes:
>>>
>>>>> While it may be true that you can have bare worktrees; I would question
>>>>> why anyone wants to do this, as the only thing it provides is an
>>>>> additional HEAD (plus its reflog).
>>>>
>>>> A more plausible situation is you start with a bare one as the
>>>> primary and used to make local clones to do your work in the world
>>>> before "git worktree".  It would be a natural extension to your
>>>> workflow to instead create worktrees of of that bare one as the
>>>> primary worktree with secondaries with working trees.
>>>
>>> For what it's worth, this conversation makes me think it was a mistake
>>> to call this construct a worktree.
>>
>> For the record, I am totally confused with Junio's last line, with two
>> "with"s, "worktree" and "working trees" in the same phrase :D
>
> In case this wasn't just a tangential note, what I meant was:
>
>  - In the old world, you may have had a single bare repository and
>    then made clones, each of which has a working tree (i.e. non-bare
>    clones), and worked inside these clones.
>
>  - In the "git worktree" world, you can start from that same single
>    bare repository, but instead of cloning it, use "git worktree" to
>    create "worktree"s, each of which has a working tree, and work
>    inside these "worktree"s.
>
> and the latter would be a natural extension to the workflow the
> former wanted to use.

Yes I really want that, and even the ability to convert a normal one repo (with one working tree) to the latter, moving the repository to somewhere safe.

Show 10 quoted lines
>>> It's fine for the command to have one name and the documentation to
>>> use a longer, clearer name to explain it.  What should that longer,
>>> clearer name be?
>>
>> No comments from me. I'll let you know that if Eric (or Junio?) didn't
>> stop me, we would have had $GIT_DIR/repos now instead of
>> $GIT_DIR/worktrees, just some extra confusion toppings.
>
> I forgot about that part of the history, but you are saying you
> wanted to call these "repos", not "worktrees"?

From $GIT_DIR perspective (which points to $GIT_COMMON_DIR/worktrees/blah) then they do look like a repository with lots of part borrowed from $GIT_COMMON_DIR. I was simply saying I'm bad at naming things. "worktrees" is a better name than "repos".

Show 5 quoted lines
> I can see why
> somebody (or me?) would stop that by fearing "repo" is a bit too
> confusing with a "repository", in the same way that we are now
> realizing that "worktree" is too similar to an old synonym we used
> to call "working tree".
-- 
Duy
Previous: Jacob KellerNext: Junio C Hamano
Message 43 of 53 in “git-prompt.sh: Full patch for submodule indicator”
  1. 0/4 git-prompt.sh: Full patch for submodule indicatorBenjamin Fuchs, Jan 30, 2017
  2. 3/4 git-prompt.sh: fix for submodule 'dirty' indicatorBenjamin Fuchs, Jan 30, 2017
  3. 4/4 git-prompt.sh: add tests for submodule indicatorBenjamin Fuchs, Jan 30, 2017
  4. SZEDER GáborJan 31, 2017
  5. Junio C HamanoJan 31, 2017
  6. Stefan BellerJan 31, 2017
  7. rev-parse: add --show-superproject-working-treeStefan Beller, Mar 7, 2017
  8. Junio C HamanoMar 7, 2017
  9. Junio C HamanoMar 7, 2017
  10. Junio C HamanoMar 7, 2017
  11. Junio C HamanoMar 7, 2017
  12. Stefan BellerMar 7, 2017
  13. Junio C HamanoMar 7, 2017
  14. [PATCHv2] rev-parse: add --show-superproject-working-treeStefan Beller, Mar 8, 2017
  15. Junio C HamanoMar 8, 2017
  16. [PATCHv3] rev-parse: add --show-superproject-working-treeStefan Beller, Mar 8, 2017
  17. Junio C HamanoMar 8, 2017
  18. [PATCHv4] rev-parse: add --show-superproject-working-treeStefan Beller, Mar 8, 2017
  19. Junio C HamanoMar 8, 2017
  20. Jonathan NiederMar 17, 2017
  21. Documentation/git-worktree: use working tree for trees on the file systemStefan Beller, Mar 17, 2017
  22. Jonathan NiederMar 17, 2017
  23. Stefan BellerMar 17, 2017
  24. Junio C HamanoMar 18, 2017
  25. Junio C HamanoMar 18, 2017
  26. Junio C HamanoMar 18, 2017
  27. Stefan BellerMar 20, 2017
  28. Junio C HamanoMar 20, 2017
  29. Jonathan NiederMar 20, 2017
  30. 0/2 use "working trees" instead of "worktree" in our APIStefan Beller, Mar 20, 2017
  31. 2/2 revparse: introduce --is-inside-working-treeStefan Beller, Mar 20, 2017
  32. Jonathan NiederMar 20, 2017
  33. 1/2 git.c: introduce --working-tree superseding --work-treeStefan Beller, Mar 20, 2017
  34. Jonathan NiederMar 20, 2017
  35. Junio C HamanoMar 20, 2017
  36. Duy NguyenMar 21, 2017
  37. Junio C HamanoMar 21, 2017
  38. Michael J GruberMar 23, 2017
  39. Junio C HamanoMar 23, 2017
  40. Duy NguyenMar 25, 2017
  41. Michael J GruberApr 7, 2017
  42. Jacob KellerApr 7, 2017
  43. Duy NguyenMar 25, 2017
  44. Junio C HamanoMar 8, 2017
  45. 2/4 git-prompt.sh: rework of submodule indicatorBenjamin Fuchs, Jan 30, 2017
  46. SZEDER GáborJan 31, 2017
  47. 1/4 git-prompt.sh: add submodule indicatorBenjamin Fuchs, Jan 30, 2017
  48. Junio C HamanoJan 30, 2017
  49. Benjamin FuchsJan 31, 2017
  50. Junio C HamanoJan 31, 2017
  51. Stefan BellerFeb 6, 2017
  52. Jacob KellerFeb 6, 2017
  53. Stefan BellerFeb 6, 2017

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.