Thread (3 messages) 3 messages, 3 authors, 2017-03-25

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 :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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help