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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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

Ciao,
Dscho