Duy Nguyen <pclo...@gmail.com> writes: >> 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 :)
I actually would ;-) If I had to choose between the two, I'd prefer to see this new feature as part of the "worktree" subcommand, simply because "branch" is a fairly basic feature that can be used by those who are new to Git without knowing that the "worktree" feature even exists (hence not having to have one extra option description in its documentation that talks about "worktree" is a big plus). But that is only if I had to choose between the two. Personally, I think you are better off implementing this set of features as a set of shell aliases (be it bash or tcsh). For one thing, you are likely to want to "chdir" to the newly created worktree built for the branch (or an existing one for the named branch) for the "take me to a worktree to work on this branch" feature. The last action you would want that command to take is to take you there, and "git anything" subcommand would not let you do that (unless you tell your users to run "eval `git something`", a way similar to "ssh-agent -s", that is). That approach to implement the UI that directly faces the end users via scripting would let your users choose layouts more flexibly. Some people may want a repository and its worktrees next to each other, some others may want the worktrees embedded inside the main repository, yet some others may want layouts other than those two. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
