threads / patch / 41661

patchIntroduce a way to create a branch and worktree at the same time

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

## tl;dr

16 messages between Mar 10, 2016 and Mar 15, 2016. Diffs are folded; open one to read it.

replies: 15people: 6as markdown or json

Johannes Schindelin· Mar 10, 2016, 11:34 UTC · lore

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
Johannes Schindelin· Mar 10, 2016, 11:34 UTC · re: Johannes Schindelin · lore

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

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(-)
Show changes to 2 files +28 −4

Documentation/git-branch.txt, builtin/branch.c

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
Duy Nguyen· Mar 10, 2016, 11:51 UTC · re: Johannes Schindelin · lore

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

On Thu, Mar 10, 2016 at 6:34 PM, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:

Show 8 quoted lines
> 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?

Show 5 quoted lines
> 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.

Show 5 quoted lines
> 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
Duy Nguyen· Mar 10, 2016, 11:59 UTC · re: Duy Nguyen · lore

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

On Thu, Mar 10, 2016 at 6:51 PM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 6 quoted lines
>> 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
Johannes Schindelin· Mar 10, 2016, 13:24 UTC · re: Duy Nguyen · lore

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:
Show 13 quoted lines
> 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

Johannes Schindelin· Mar 10, 2016, 13:21 UTC · re: Duy Nguyen · lore

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:
Show 14 quoted lines
> 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.

Show 10 quoted lines
> > 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.

Show 15 quoted lines
> > 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

Duy Nguyen· Mar 11, 2016, 00:56 UTC · re: Johannes Schindelin · lore

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

On Thu, Mar 10, 2016 at 8:21 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 25 quoted lines
> 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?

Show 11 quoted lines
>> > 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 :)
Show 23 quoted lines
>> > 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
Junio C Hamano· Mar 11, 2016, 06:43 UTC · re: Duy Nguyen · lore

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

Duy Nguyen <pclouds@gmail.com> writes:
Show 5 quoted lines
>> 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.

Johannes Schindelin· Mar 15, 2016, 06:53 UTC · re: Junio C Hamano · lore

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

Hi Junio,
On Thu, 10 Mar 2016, Junio C Hamano wrote:
Show 14 quoted lines
> 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.
Show 5 quoted lines
> 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

Duy Nguyen· Mar 15, 2016, 10:34 UTC · re: Johannes Schindelin · lore

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

On Tue, Mar 15, 2016 at 1:53 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 8 quoted lines
>> 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
Johannes Schindelin· Mar 15, 2016, 13:56 UTC · re: Duy Nguyen · lore

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

Hi Duy,
On Tue, 15 Mar 2016, Duy Nguyen wrote:
Show 12 quoted lines
> 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

Duy Nguyen· Mar 15, 2016, 14:07 UTC · re: Johannes Schindelin · lore

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

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
Mikael Magnusson· Mar 11, 2016, 02:57 UTC · re: Johannes Schindelin · lore

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

On Thu, Mar 10, 2016 at 2:21 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 29 quoted lines
> 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
Johannes Schindelin· Mar 14, 2016, 13:45 UTC · re: Mikael Magnusson · lore

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

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

Johannes Sixt· Mar 15, 2016, 20:40 UTC · re: Mikael Magnusson · lore

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

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
Eric Sunshine· Mar 10, 2016, 20:45 UTC · re: Duy Nguyen · lore

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

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

← back to recent threads