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: Sun, 5 Jan 2020 23:20:41 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Dec 27, 2019 at 6:05 AM Eric Sunshine <> wrote:
> On Sat, Dec 14, 2019 at 11:16 AM Pratyush Yadav <> wrote:
> > When no branch name is supplied to 'worktree add', it creates a new
> > branch based on the name of the directory the new worktree is located
> > in. But when the worktree is later removed, that created branch is left
> > over.
> This is describing the existing (intentional) behavior but doesn't
> explain why this might be annoying or problematic. To help sell the
> patch, it might make sense to say something about how the behavior can
> trip up newcomers to git-worktree, leaving them to wonder why they are
> accumulating so many branches that they weren't aware they created. A
> comment about why you think "git worktree add -d foo" is not a viable
> way to side-step the creation of unwanted branches might also be
> worthwhile.

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.

Some points in favor of just updating the documentation to address
this issue (rather than implementing the new behavior suggested by
this patch) include:

* far simpler; no code to implement or debug

* no (surprising) behavior changes

* "git worktree add -d foo" is about as easy to type and remember as
  "git worktree add foo"

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

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.

  parent reply	other threads:[~2020-01-06  4:20 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 [this message]
2020-01-06 18:01       ` Pratyush Yadav
2020-01-09  9:46         ` Eric Sunshine

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 \
    --in-reply-to='' \ \ \ \

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