Re: [PATCH v3 10/21] checkout: split part of it to new command 'switch'

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Mar 12, 2019, 17:28 UTC
Message-ID: <CAPig+cSe-v-GU=UG_PyUjf9itz_Ddqq4-Ni4h=2TtbLDXr5WJA@mail.gmail.com>
In-Reply-To: <CABPp-BHpoa+tNW=7+6TOmoQTvbap3iavqApEGny4E-rwv1gZVQ@mail.gmail.com>

On Tue, Mar 12, 2019 at 12:51 PM Elijah Newren <newren@gmail.com> wrote:

Show 16 quoted lines

> On Tue, Mar 12, 2019 at 8:37 AM Eric Sunshine <sunshine@sunshineco.com> 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.

Show 8 quoted lines

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