On Fri, Dec 27, 2019 at 6:05 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > On Sat, Dec 14, 2019 at 11:16 AM Pratyush Yadav <me@xxxxxxxxxxxxxxxxx> 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.
