From: Junio C Hamano <firstname.lastname@example.org> To: Duy Nguyen <email@example.com> Cc: Jonathan Nieder <firstname.lastname@example.org>, Stefan Beller <email@example.com>, "git\@vger.kernel.org" <firstname.lastname@example.org> Subject: Re: [PATCH] Documentation/git-worktree: use working tree for trees on the file system Date: Tue, 21 Mar 2017 08:48:32 -0700 Message-ID: <email@example.com> (raw) In-Reply-To: <CACsJy8CBmfj8wY+LQzEshJT0Ya+nmAGs=K8b1Nyr3qinvCo4kA@mail.gmail.com> Duy Nguyen <firstname.lastname@example.org> writes: > On Tue, Mar 21, 2017 at 1:50 AM, Jonathan Nieder <email@example.com> wrote: >> Junio C Hamano wrote: >>> Stefan Beller <firstname.lastname@example.org> 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".
next prev parent reply index Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-01-30 20:44 [PATCH 0/4] git-prompt.sh: Full patch for submodule indicator Benjamin Fuchs 2017-01-30 20:44 ` [PATCH 1/4] git-prompt.sh: add " Benjamin Fuchs 2017-01-30 23:48 ` Junio C Hamano 2017-01-31 0:10 ` Benjamin Fuchs 2017-01-31 3:11 ` Junio C Hamano 2017-02-06 4:23 ` Stefan Beller 2017-02-06 5:55 ` Jacob Keller 2017-02-06 10:13 ` Stefan Beller 2017-01-30 20:44 ` [PATCH 2/4] git-prompt.sh: rework of " Benjamin Fuchs 2017-01-30 20:44 ` [PATCH 4/4] git-prompt.sh: add tests for " Benjamin Fuchs 2017-01-31 18:32 ` SZEDER Gábor 2017-01-31 22:06 ` Junio C Hamano 2017-01-31 22:12 ` Stefan Beller 2017-03-07 3:45 ` [RFC PATCH] rev-parse: add --show-superproject-working-tree Stefan Beller 2017-03-07 5:13 ` Junio C Hamano 2017-03-07 7:16 ` Junio C Hamano 2017-03-07 7:23 ` Junio C Hamano 2017-03-07 18:44 ` Junio C Hamano 2017-03-07 20:40 ` Stefan Beller 2017-03-07 22:49 ` Junio C Hamano 2017-03-08 0:56 ` [PATCHv2] " Stefan Beller 2017-03-08 1:30 ` Junio C Hamano 2017-03-08 6:01 ` Junio C Hamano 2017-03-08 19:20 ` [PATCHv3] " Stefan Beller 2017-03-08 22:28 ` Junio C Hamano 2017-03-08 23:07 ` [PATCHv4] " Stefan Beller 2017-03-08 23:51 ` Junio C Hamano 2017-03-17 22:28 ` Jonathan Nieder 2017-03-17 22:51 ` [PATCH] Documentation/git-worktree: use working tree for trees on the file system Stefan Beller 2017-03-17 22:55 ` Jonathan Nieder 2017-03-17 23:04 ` Stefan Beller 2017-03-18 17:24 ` Junio C Hamano 2017-03-18 1:47 ` Junio C Hamano 2017-03-18 1:36 ` Junio C Hamano 2017-03-20 17:29 ` Stefan Beller 2017-03-20 18:12 ` Junio C Hamano 2017-03-20 18:50 ` Jonathan Nieder 2017-03-20 19:22 ` [PATCH 0/2] use "working trees" instead of "worktree" in our API Stefan Beller 2017-03-20 19:22 ` [PATCH 1/2] git.c: introduce --working-tree superseding --work-tree Stefan Beller 2017-03-20 19:58 ` Jonathan Nieder 2017-03-20 19:22 ` [PATCH 2/2] revparse: introduce --is-inside-working-tree Stefan Beller 2017-03-20 20:00 ` Jonathan Nieder 2017-03-20 19:37 ` [PATCH 0/2] use "working trees" instead of "worktree" in our API Junio C Hamano 2017-03-21 10:37 ` [PATCH] Documentation/git-worktree: use working tree for trees on the file system Duy Nguyen 2017-03-21 15:48 ` Junio C Hamano [this message] 2017-03-23 17:06 ` Michael J Gruber 2017-03-23 17:55 ` Junio C Hamano 2017-03-25 12:07 ` Duy Nguyen 2017-04-07 13:59 ` Michael J Gruber 2017-04-07 16:14 ` Jacob Keller 2017-03-25 12:05 ` Duy Nguyen
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
email@example.com mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox