mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <>
To: Pratyush Yadav <>
Cc: Git List <>
Subject: Re: [PATCH 1/1] worktree: delete branches auto-created by 'worktree add'
Date: Thu, 9 Jan 2020 04:46:57 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jan 6, 2020 at 1:01 PM Pratyush Yadav <> wrote:
> On 05/01/20 11:20PM, Eric Sunshine wrote:
> > On Fri, Dec 27, 2019 at 6:05 AM Eric Sunshine <> wrote:
> > As an alternative to this patch, would the simpler approach of
> > improving git-worktree documentation to do a better job of pointing
> > people at -d/--detach as a way to side-step unwanted branch creation
> > make sense? That is, at minimum, enhance the "Description" section to
> > prominently talk about throwaway worktrees (created with -d/--detach),
> > and add an example to the "Examples" section (perhaps as the first
> > example) showing creation/use/deletion of a throwaway worktree.
> FYI, I'm running Git v2.24.1 and 'git worktree add' doesn't accept the
> option '-d'. It only accepts '--detach'. And looking at the current
> 'next', I don't see the option mentioned in git-worktree.txt. So at the
> very least, we should start by actually adding the option.

I forgot that -d was never added as shorthand for --detach, and didn't
bother checking the man page. But, yes, adding -d would be a good

> > Of lesser importance, it might make sense, as a followup, to add a
> > configuration which changes the default behavior to detach instead of
> > auto-creating a branch. I wonder if this could be piggybacked on the
> > existing "worktree.guessremote" configuration. Or rather,
> > retire/deprecate that configuration and add a new one which affects
> > DWIM'ing behavior such that it becomes multi-state. Some possible
> > values for the new configuration: "auto" (or "dwim" or whatever),
> > "guessremote", "detach". (I haven't thought this through thoroughly,
> > so there might be holes in my suggestion.)
> Honestly, coupled with a configuration variable this alternative fits my
> use-case really well.
> I think 'guessremote' does not describe very well what the config
> variable would actually do. So I think deprecating it would be a better
> idea.
> Does 'worktree.newBranch' sound like a good name? (Disclaimer: I am
> terrible at naming things).

Maybe 'worktree.addFlags' or something? I'm thinking that this might
be a multi-value configuration variable which is a combination of the
various option flags which can be used with "git worktree add". For
instance: 'worktree.addFlags=detach' or
worktree.addFlags=auto-create-branch,guess-remote. Possible values
might include:

    enable/disable automatic branch creation when <commit-ish> is

    create worktree with detached HEAD

    perform/suppress checkout of <commit-ish> in the new worktree

    create local branch from remote-tracking branch if present and
    <commit-ish> omitted

    make new branch track <commit-ish> if the latter is a branch name

    keep worktree locked after creation

In fact, I'd like to see 'auto-create-branch' incorporate
'guess-remote' behavior by default since "remote guessing" should have
been the default behavior from day one, but it was overlooked. The
--guess-remote option was added simply to avoid backward compatibility
problems, but it would be nice to one day make it the default. Since
this configuration variable is new, we don't have to worry about
backward compatibility with it, thus can make 'auto-create-branch'
work like it should have from inception -- that is, performing "remote
guessing" DWIMing (just like "git checkout" does by default).

A command-line option would (as expected) override a flag set via
'worktree.addFlags'. So, for instance, --no-detach would override

Anyhow, this is just a rough idea. I haven't thought through all the
ramifications, or even if this is a sane interface.

> > There's at least one point not in favor of merely updating the
> > documentation to promote -d/--detach more heavily, and that is that
> > (presumably) the concept of detached HEAD is perceived as an advanced
> > topic, so it may not be suitable for the newcomer or casual user.
> I'm basing this off no data so take it with a grain of salt, but I think
> people who know Git enough to understand the concept of multiple
> worktrees should also understand what a detached HEAD is. And even if
> they already don't know what it is, they should have no trouble quickly
> reading one of the many great explanations available with a simple
> Google search.

I don't necessarily share that opinion, but I do think that if we add
-d as shorthand for --detach, and do a really good job of updating the
documentation to promote the idea of "throwaway worktrees" (which also
happen to be detached), then we have a good path forward.

> My argument in favor of auto-deletion is that we should still try to
> have sane defaults. Leaving behind a branch the user didn't explicitly
> create and didn't use doesn't sound like a sane default to me.
> The configuration variable path is easier and suits my needs really
> well, so I am inclined to just go with it. But making the whole user
> experience better for everyone is still something worthwhile. But then
> again, introducing a backwards-incompatible change might not be the best
> idea. So, I dunno.

Yep, the different ideas can co-exist, and each can be implemented
without promising to implement the others. A good first step would be
to add -d as alias for --detach and update the documentation to
promote the concept of "throwaway worktrees". An optional second step
(if needed) would be that new configuration variable (though it still
needs more thought). And, a really optional third step (if anyone
cares strongly enough) would be to implement auto-deletion of
auto-created branches.

      reply	other threads:[~2020-01-09  9:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-14 16:14 [PATCH 0/1] worktree: delete branches auto-created by 'worktree add' Pratyush Yadav
2019-12-14 16:14 ` [PATCH 1/1] " Pratyush Yadav
2019-12-18 19:31   ` Pratyush Yadav
2019-12-18 19:34     ` Eric Sunshine
2019-12-27 11:05   ` Eric Sunshine
2020-01-04 21:47     ` Pratyush Yadav
2020-01-05  5:32     ` Eric Sunshine
2020-01-06  4:20     ` Eric Sunshine
2020-01-06 18:01       ` Pratyush Yadav
2020-01-09  9:46         ` Eric Sunshine [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).