Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Mar 14, 2016, 13:45 UTC
- Message-ID
- <alpine.DEB.2.20.1603141445140.4690@virtualbox>
- In-Reply-To
- <CAHYJk3Sij4tH0i29Asahjj8KBdQj59jFRTCoYzO_XE_kt3SnDw@mail.gmail.com>
Hi Mikael,
On Fri, 11 Mar 2016, Mikael Magnusson wrote:
Show 39 quoted lines
> On Thu, Mar 10, 2016 at 2:21 PM, Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > Hi Duy, > > > > On Thu, 10 Mar 2016, Duy Nguyen wrote: > > > >> On Thu, Mar 10, 2016 at 6:34 PM, Johannes Schindelin > >> <johannes.schindelin@gmx.de> wrote: > >> > One possible improvement would be to add "/xyz/" to the parent > >> > repository's .git/info/exclude, but this developer hesitates to > >> > introduce that feature without the "delete" counterpart: those exclude > >> > entries would likely go stale very quickly. Besides, there might be a > >> > plan in the working to exclude worktrees automagically? > >> > >> That's needed because you add a worktree inside another worktree? I > >> know that feeling, but I've changed my layout from ~/w/git as main > >> worktree (and ~/w/git/.git as repo) to ~/w/git as a non-worktree dir > >> that contains all worktrees, e.g. ~/w/git/reinclude-dir, > >> ~/w/git/worktree-config, ~/w/git/lmdb... My typical worktree add > >> command is "git worktree add ../<some-name>" then move there and do > >> stuff. No nested worktrees, no need to update exclude file (and no > >> messing up emacs' rgrep command, which does not understand .gitignore > >> anyway) > > > > This feels to me like it is working around the problem rather than solving > > it. My worktrees are inside the corresponding top-level project for a > > reason: I work with multiple projects, and having all of their worktrees > > in a single $HOME/w/ directory would be rather confusing to me. > > > > I really want to keep my Git worktrees inside /usr/src/git/ (in Git for > > Windows' SDK). > > You can have /usr/src/git/master, /usr/src/git/some-work-tree, etc, > and /usr/src/git itself is not a git repository at all. That way > /usr/src only has one git-related directory and no worktrees are > nested. The only downside is if you work in master most of the time, > you have to type "/master" more. I think this is what Duy suggested > too, but you interpreted it as having /usr/src/git-master, > /usr/src/git-some-work-tree etc?
That is a sensible workaround.
The question is: why do I need a workaround?
Ciao, Dscho