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
Michael J Gruber <git@drmicha.warpmail.net>
Date
Mar 23, 2017, 17:06 UTC
Message-ID
<3c16aea8-be53-ef41-d43f-7b4e8ca15d7d@drmicha.warpmail.net>
In-Reply-To
<xmqqvar2ska7.fsf@gitster.mtv.corp.google.com>
Junio C Hamano venit, vidit, dixit 21.03.2017 16:48:
Show 51 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.
> 
>>> 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"?  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".
> 
I would say the new thing is really a "checkout", but that opens another
can of worms. On the other hand, "git checkout" already does:
- switching of branches
- creation of branches
- detaching of head
- partial updates of the working tree
So why shouldn't it manage worktrees, as well?

While that may sound a bit sarcastic it indicates that we may want to rethink some things at some point rather than adding up to the conflation. The discussion in this thread seems to show that "worktree" is just as a good a name for the new feature, while "workbase" or "workroot" (or "workdir") or so could have been for the old one.

Are we at a point where we can still rename the new feature at least? If yes, and keeping everything else is mandatory, than "workspace" or "working space" may be a serious contender for naming the new thing.

Michael
Previous: Junio C HamanoNext: Junio C Hamano
Message 38 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.