Re: [PATCH] Documentation/git-worktree: use working tree for trees on the file system
From: Duy Nguyen <hidden>
Date: 2017-03-25 12:05:46
On Tue, Mar 21, 2017 at 10:48 PM, Junio C Hamano [off-list ref] wrote:
Duy Nguyen [off-list ref] writes:quoted
On Tue, Mar 21, 2017 at 1:50 AM, Jonathan Nieder [off-list ref] wrote:quoted
Junio C Hamano wrote:quoted
Stefan Beller [off-list ref] writes:quoted
quoted
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 :DIn 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.
quoted
quoted
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".
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