git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Pratyush Yadav <me@yadavpratyush.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 1/1] worktree: delete branches auto-created by 'worktree add'
Date: Mon, 6 Jan 2020 23:31:01 +0530	[thread overview]
Message-ID: <20200106180101.wwznvthla35x3qd2@yadavpratyush.com> (raw)
In-Reply-To: <CAPig+cQmqKiYWDWFH5eK2S6XPOi2t2+8Oas8yZa8R=bKLym3wQ@mail.gmail.com>

On 05/01/20 11:20PM, Eric Sunshine wrote:
> On Fri, Dec 27, 2019 at 6:05 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > On Sat, Dec 14, 2019 at 11:16 AM Pratyush Yadav <me@yadavpratyush.com> 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"

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

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.

-- 
Regards,
Pratyush Yadav

  reply	other threads:[~2020-01-06 18:01 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 [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20200106180101.wwznvthla35x3qd2@yadavpratyush.com \
    --to=me@yadavpratyush.com \
    --cc=git@vger.kernel.org \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://80x24.org/mirrors/git.git

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