On Tue, Mar 12, 2019 at 12:51 PM Elijah Newren <newren@xxxxxxxxx> wrote: > On Tue, Mar 12, 2019 at 8:37 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > > It's not much of a datapoint, but I do use "git checkout -B" (and > > therefore would use "git switch -C") periodically (in addition to > > -b/-c, which I use all the time). And, convenience is important, > > especially considering that "git switch" is already more painful in > > some ways than "git checkout", due to having to trigger and spell out > > certain things explicitly (such as detaching). > > Ooh, interesting. I haven't used it and didn't know who did, but > since you do you can probably answer the question surrounding the > long-name for the -C option from earlier in the thread: > > Do you use checkout -B only when checkout -b fails, or do you use it > pre-emptively? The former would suggest we should use a name like > --recreate, while the latter would suggest a name more like > --force-create. It doesn't come up often, but I use "git checkout -B" when I know that I want to start an existing branch over from scratch to build upon some unrelated branch. This almost always happens when I'm programming experimentally. I'll create a new branch with the desired _final_ name, start work on it, realize that some other approach might be better, so set that aside and create a new branch with some junk name, work on that for a while, possibly repeat, creating more branches with more junk names, etc. Sometimes the result is that bits a pieces of the various junk-named branches can be pulled together into a final product, in which case I may "git checkout -B <final>", overwriting the first branch I created, and then pull a few things from other junk-named branches to reach the end. (More often, though, one of the junk-named branches ends up being what I want to go with, so I just "git branch -M <final>", throwing away the original branch, and keeping the junk-named one but with the _final_ name). Sorry for the too long-winded explanation. I think --force-create is a better name because "force" implies strongly that you're doing something potentially dangerous. Also, every option in git-branch which deletes or overwrites a branch name requires "force", so it's good precedent to follow. > > Again, not much of a datapoint, but I do use --orphan periodically. > > The idea of "fixing" the behavior so that --orphan starts with a clean > > slate is certainly appealing (since it matches how I've used orphan > > branches in each case). > > The only three people who have commented on --orphan in this thread > all apparently feel the same way: the current behavior is wrong. > Maybe we can switch it to start with an empty index after all? Starting empty may match intuition better. (More importantly, perhaps, it's harder to come up with a use-case for --orphan which doesn't involve starting with a clean slate.)
