On Thu, Mar 10, 2016 at 8:21 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi Duy, > > On Thu, 10 Mar 2016, Duy Nguyen wrote: > >> On Thu, Mar 10, 2016 at 6:34 PM, Johannes Schindelin >> <johannes.schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html