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

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

[Johannes Schindelin]

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

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?


Johannes Schindelin (1):
  branch: allow conveniently adding new worktrees for new branches

 Documentation/git-branch.txt |  5 +++--
 builtin/branch.c             | 27 +++++++++++++++++++++++++--
 2 files changed, 28 insertions(+), 4 deletions(-)

-- 
2.7.2.windows.1.8.g47d64e6.dirty

[PATCH 1/1] branch: allow conveniently adding new worktrees for new branches

[Johannes Schindelin]

With the newly-introduced --worktree option, after a new branch was
created we will add a corresponding new worktree with the same name
automatically.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/git-branch.txt |  5 +++--
 builtin/branch.c             | 27 +++++++++++++++++++++++++--
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 4a7037f..963cdcb 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -13,7 +13,7 @@ SYNOPSIS
 	[--column[=<options>] | --no-column]
 	[(--merged | --no-merged | --contains) [<commit>]] [--sort=<key>]
 	[--points-at <object>] [<pattern>...]
-'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
+'git branch' [--set-upstream | --track | --no-track] [-l] [-f] [-w | --worktree] <branchname> [<start-point>]
 'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
 'git branch' --unset-upstream [<branchname>]
 'git branch' (-m | -M) [<oldbranch>] <newbranch>
@@ -46,7 +46,8 @@ which points to the current 'HEAD', or <start-point> if given.
 
 Note that this will create the new branch, but it will not switch the
 working tree to it; use "git checkout <newbranch>" to switch to the
-new branch.
+new branch, or use the `--worktree` option to add a new worktree of
+the same name.
 
 When a local branch is started off a remote-tracking branch, Git sets up the
 branch (specifically the `branch.<name>.remote` and `branch.<name>.merge`
diff --git a/builtin/branch.c b/builtin/branch.c
index 7b45b6b..c681b2e 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -20,6 +20,7 @@
 #include "utf8.h"
 #include "wt-status.h"
 #include "ref-filter.h"
+#include "run-command.h"
 
 static const char * const builtin_branch_usage[] = {
 	N_("git branch [<options>] [-r | -a] [--merged | --no-merged]"),
@@ -605,7 +606,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 {
 	int delete = 0, rename = 0, force = 0, list = 0;
 	int reflog = 0, edit_description = 0;
-	int quiet = 0, unset_upstream = 0;
+	int quiet = 0, unset_upstream = 0, new_worktree = 0;
 	const char *new_upstream = NULL;
 	enum branch_track track;
 	struct ref_filter filter;
@@ -622,6 +623,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 			BRANCH_TRACK_OVERRIDE),
 		OPT_STRING('u', "set-upstream-to", &new_upstream, "upstream", "change the upstream info"),
 		OPT_BOOL(0, "unset-upstream", &unset_upstream, "Unset the upstream info"),
+		OPT_BIT('w', "worktree", &new_worktree, N_("add worktree for the new branch"), 1),
 		OPT__COLOR(&branch_use_color, N_("use colored output")),
 		OPT_SET_INT('r', "remotes",     &filter.kind, N_("act on remote-tracking branches"),
 			FILTER_REFS_REMOTES),
@@ -678,6 +680,13 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 	if (!delete && !rename && !edit_description && !new_upstream && !unset_upstream && argc == 0)
 		list = 1;
 
+	if (new_worktree) {
+		if (delete || rename || new_upstream || unset_upstream)
+			die("--worktree requires creating a new branch");
+		if (new_worktree && (argc < 1 || argc > 2))
+			die(_("--worktree needs a branch/worktree name"));
+	}
+
 	if (filter.with_commit || filter.merge != REF_FILTER_MERGED_NONE || filter.points_at.nr)
 		list = 1;
 
@@ -797,7 +806,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 		strbuf_release(&buf);
 	} else if (argc > 0 && argc <= 2) {
 		struct branch *branch = branch_get(argv[0]);
-		int branch_existed = 0, remote_tracking = 0;
+		int branch_existed = 0, remote_tracking = 0, res = 0;
 		struct strbuf buf = STRBUF_INIT;
 
 		if (!strcmp(argv[0], "HEAD"))
@@ -820,6 +829,17 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 		create_branch(head, argv[0], (argc == 2) ? argv[1] : head,
 			      force, reflog, 0, quiet, track);
 
+		if (new_worktree) {
+			const char *child_argv[] = {
+				"worktree", "add", NULL, NULL, NULL
+			};
+			child_argv[2] = child_argv[3] = argv[0];
+			if ((res = run_command_v_opt(child_argv, RUN_GIT_CMD)))
+				error(_("Could not create worktree %s"), argv[0]);
+			else
+				fprintf(stderr, _("New worktree set up at %s\n"), argv[0]);
+		}
+
 		/*
 		 * We only show the instructions if the user gave us
 		 * one branch which doesn't exist locally, but is the
@@ -828,10 +848,13 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 		if (argc == 1 && track == BRANCH_TRACK_OVERRIDE &&
 		    !branch_existed && remote_tracking) {
 			fprintf(stderr, _("\nIf you wanted to make '%s' track '%s', do this:\n\n"), head, branch->name);
+			if (new_worktree)
+				fprintf(stderr, _("    # remove worktree %s/\n"), branch->name);
 			fprintf(stderr, _("    git branch -d %s\n"), branch->name);
 			fprintf(stderr, _("    git branch --set-upstream-to %s\n"), branch->name);
 		}
 
+		return res;
 	} else
 		usage_with_options(builtin_branch_usage, options);
 
-- 
2.7.2.windows.1.8.g47d64e6.dirty

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

[Duy Nguyen]

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?

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

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

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

[Duy Nguyen]

On Thu, Mar 10, 2016 at 6:51 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> 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?

Another option is just do "worktree -b xyz . upstream/master"

when the destination already exists and is a directory, the real
worktree location is <dest>/<branch name>. Similar to "mv abc def"
becomes "mv abc def/abc" when def is already a directory.
-- 
Duy

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

[Johannes Schindelin]

Hi Duy,

On Thu, 10 Mar 2016, Duy Nguyen wrote:

> On Thu, Mar 10, 2016 at 6:51 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> >> 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?
> 
> Another option is just do "worktree -b xyz . upstream/master"
> 
> when the destination already exists and is a directory, the real
> worktree location is <dest>/<branch name>. Similar to "mv abc def"
> becomes "mv abc def/abc" when def is already a directory.

Hmm. That sounds too clever to me. It is clever, alright, but it is also
confusing: "Wait, what? Where is my... Darn! It already existed! And now I
have my-cool-worktree/my-cool-worktree/! Blergh."

Please count that as mild opposition to that idea :-)

Ciao,
Dscho

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

[Johannes Schindelin]

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

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

[Duy Nguyen]

On Thu, Mar 10, 2016 at 8: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:
>> > 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.

This assumes the new worktree is always placed at `cwd`. Perhaps it's
too specific?

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

If you put effort into making it happen, I'm not stopping you :)

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

I avoided it because adapting git alone was not enough, emacs' rgrep
is just an example that other tools may have problems with this setup
too. But if you still want to make git exclude them, I think you
should hook into the submodule peeking code instead of updating
exclude file. It sounds neater to me.

But if you go with exclude auto update, it's about time we introduce
multiple exclude files in $GIT_DIR/info. So you can separate auto
stuff from manual exclude rules.
-- 
Duy

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

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

>> 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.
>
> If you put effort into making it happen, I'm not stopping you :)

I actually would ;-)  If I had to choose between the two, I'd prefer
to see this new feature as part of the "worktree" subcommand, simply
because "branch" is a fairly basic feature that can be used by those
who are new to Git without knowing that the "worktree" feature even
exists (hence not having to have one extra option description in its
documentation that talks about "worktree" is a big plus).

But that is only if I had to choose between the two.

Personally, I think you are better off implementing this set of
features as a set of shell aliases (be it bash or tcsh).  For one
thing, you are likely to want to "chdir" to the newly created
worktree built for the branch (or an existing one for the named
branch) for the "take me to a worktree to work on this branch"
feature.  The last action you would want that command to take is to
take you there, and "git anything" subcommand would not let you do
that (unless you tell your users to run "eval `git something`", a
way similar to "ssh-agent -s", that is).

That approach to implement the UI that directly faces the end users
via scripting would let your users choose layouts more flexibly.
Some people may want a repository and its worktrees next to each
other, some others may want the worktrees embedded inside the main
repository, yet some others may want layouts other than those two.

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

[Johannes Schindelin]

Hi Junio,

On Thu, 10 Mar 2016, Junio C Hamano wrote:

> Duy Nguyen <pclouds@gmail.com> writes:
> 
> >> 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.
> >
> > If you put effort into making it happen, I'm not stopping you :)
> 
> I actually would ;-)  If I had to choose between the two, I'd prefer
> to see this new feature as part of the "worktree" subcommand, simply
> because "branch" is a fairly basic feature that can be used by those
> who are new to Git without knowing that the "worktree" feature even
> exists (hence not having to have one extra option description in its
> documentation that talks about "worktree" is a big plus).

I, in contrast, think it woild make for an excellent way to let users who
are in the dear need for the worktree feature (like myself) find out about
it.

Nobody reads release notes, but at least some people read man pages.

> Personally, I think you are better off implementing this set of
> features as a set of shell aliases (be it bash or tcsh).

True, if I was simply selfish, I would use shell aliases, too.

But I want others to benefit from my work, too, hence the patch.

> That approach to implement the UI that directly faces the end users
> via scripting would let your users choose layouts more flexibly.
> Some people may want a repository and its worktrees next to each
> other, some others may want the worktrees embedded inside the main
> repository, yet some others may want layouts other than those two.

Having the worktree in a totally different location than the associated
repository is *very* confusing. Unless, that is, you work on a single
project, ever, of course, which is a luxury typically only awarded to
maintainers, albeit not this one.

As such, *recommending* to have it elsewhere really is nothing but a
workaround for some bugs that should still be squashed instead.

Ciao,
Dscho

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

[Duy Nguyen]

On Tue, Mar 15, 2016 at 1:53 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> That approach to implement the UI that directly faces the end users
>> via scripting would let your users choose layouts more flexibly.
>> Some people may want a repository and its worktrees next to each
>> other, some others may want the worktrees embedded inside the main
>> repository, yet some others may want layouts other than those two.
>
> Having the worktree in a totally different location than the associated
> repository is *very* confusing.

I disagree (unless I misunderstood you). One of the use cases I have
for multi worktree is move all repos to a central place. Remember the
.git directory security bug? It would not happen if the repo is put
away. And it would be easier to backup repo data too. Also, "git
worktree list" is there to locate any worktree. I don't see why it's
confusing.
-- 
Duy

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

[Johannes Schindelin]

Hi Duy,

On Tue, 15 Mar 2016, Duy Nguyen wrote:

> On Tue, Mar 15, 2016 at 1:53 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >> That approach to implement the UI that directly faces the end users
> >> via scripting would let your users choose layouts more flexibly.
> >> Some people may want a repository and its worktrees next to each
> >> other, some others may want the worktrees embedded inside the main
> >> repository, yet some others may want layouts other than those two.
> >
> > Having the worktree in a totally different location than the associated
> > repository is *very* confusing.
> 
> I disagree (unless I misunderstood you).

How is it not confusing having all of your worktrees, no matter whether
they connect to git.git, to git-for-windows/build-extra.git, to
Alexpux/MSYS2-packages.git, to cygwin.git, to curl/curl.git, to
whatever.git inside $HOME/worktrees/?

I tell you how it is not confusing. It is not confusing by artificially
re-creating the hierarchy inside the $HOME/worktrees/ directory.

And you only need to re-create the hierarchy because, you guessed it, you
tried to disconnect the worktrees from their repositories.

So it is nothing but a bad old workaround, is what it is.

> One of the use cases I have for multi worktree is move all repos to a
> central place. Remember the .git directory security bug?

I remember.

> It would not happen if the repo is put away.

Sure. And with the repository being put elsewhere, you also buy the tedium
to no longer be able to simply "less .git/rebase-apply/patch". Which I
have to type *a lot*. You win some, you lose some. If you ask me, you lose
some more, but in some cases that is worth it.

> And it would be easier to backup repo data too. Also, "git worktree
> list" is there to locate any worktree. I don't see why it's confusing.

Yeah, it is clear to me now that you do not find it confusing. Even if I
find that fact in and of itself confusing, because it is very, very
confusing to me to have the repository so far away from my worktree as to
forget where it actually is, opening the door real wide for trouble e.g.
by archiving my repository behind my worktree's back.

You win some, you lose some. I am simply not prepared to lose *that* much.
My worktrees will stay inside my originally checked out working directory,
thankyouverymuch.

Ciao,
Dscho

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

[Duy Nguyen]

On Tue, Mar 15, 2016 at 8:56 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Sure. And with the repository being put elsewhere, you also buy the tedium
> to no longer be able to simply "less .git/rebase-apply/patch". Which I
> have to type *a lot*. You win some, you lose some. If you ask me, you lose
> some more, but in some cases that is worth it.

If you start to use git-worktree, you'll need to type even longer. I
notice I do and am seriously considering an alias of `git rev-parse
--git-path rebase-apply/patch` to type less temporarily. But this is
the lack of proper UI. "git rebase" should provide a way to look at
this file (and maybe some others too). I just don't know what the
option would be and how we align it with git-am, which shares this
same problem.
-- 
Duy

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

[Mikael Magnusson]

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?

-- 
Mikael Magnusson

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

[Johannes Schindelin]

Hi Mikael,

On Fri, 11 Mar 2016, Mikael Magnusson wrote:

> 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

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

[Johannes Sixt]

Am 11.03.2016 um 03:57 schrieb Mikael Magnusson:
> 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.

I started using separate worktrees recently, and I chose the layout you 
sketch here. I didn't ask someone or read any documentation to find out 
about a recommended layout. I chose the layout because it felt the most 
natural.

Never in my life would I have considered nesting worktrees inside other 
worktrees.

-- Hannes

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

[Eric Sunshine]

On Thu, Mar 10, 2016 at 6:51 AM, Duy Nguyen <pclouds@gmail.com> 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?

There's also the even shorter form:

    git worktree add pull-rebase-prefix

which creates both a branch and a worktree named "pull-rebase-prefix".
This assumes that you want the new branch based upon HEAD, which won't
work if your use-case is different and that you're not already at the
desired commit ("origin/master" in your example) when invoking the
command, though.