Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time

> 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:
>> > The invention of the `git worktree` command changed this developer's
>> > working style dramatically. Rather than switching between branches all
>> > the time, topic branches are created and checked out in newly-added
>> > worktrees, to be reworked and refined until the topic branch is either
>> > merged into `master` or abandoned.
>> >
>> > It gets rather tiresome, and also typo-prone, to call "git branch xyz
>> > upstream/master && git worktree add xyz xyz" all the time.
>>
>> You can actually do "git worktree -b xyz xyz upstream/master" for the
>> same effect. Maybe we can avoid "xyz" duplication with "-b -" or a new
>> option name?
>
> My branch names are usually longer, such as pull-rebase-prefix. And I
> really like the short 'n sweet "git branch -w pull-rebase-prefix master"
> invocation.
>
>> > Hence this
>> > proposal: "git branch -w xyz upstream/master" to do the same.

>> > The plan is to also support "git branch -d -w xyz" once the `git
>> > worktree` command learned a `remove` (or `delete`) subcommand.
>>
>> "git worktree remove" is coming (will be resent after -rc period). And
>> I agree it's convenient for it to remove the branch as well because
>> that happened to (and annoyed) me a few times. I still think it should
>> be centered around git-worktree than git-branch though.
>
> Granted, "git worktree remove" should be the work horse. But why not have
> two ways to skin the same cat? I, again, would prefer the short 'n sweet
> "git branch -d -w pull-rebase-prefix" invocation.

>> > 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).