On Tue, Mar 21, 2017 at 10:48 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Duy Nguyen <pclouds@xxxxxxxxx> writes: > >> On Tue, Mar 21, 2017 at 1:50 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >>> Junio C Hamano wrote: >>>> Stefan Beller <sbeller@xxxxxxxxxx> 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. >>> 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