Re: changing the experimental 'git switch' (was: [Summit topic] Improving Git UX)

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 22, 2021, 14:24 UTC
Message-ID: <211022.86v91pjfn7.gmgdl@evledraar.gmail.com>
In-Reply-To: <9c6b3041-a5c0-6fe1-860e-7bfcb292ae81@mfriebe.de>

On Fri, Oct 22 2021, martin wrote:

Show 23 quoted lines

> On 21/10/2021 18:45, Ævar Arnfjörð Bjarmason wrote:
>> E.g. the "-n" option to "git fetch" comes to mind, which isn't
>> a synonym for "--dry-run", as in most other places.
>>
>
> -n
> is only used very few times for dry run. I found
> git add
> git rm
> git mv
>
> But
> cherry-pick => no commit
> pull => no stat
> rebase => no stat
> merge => no stat
> fetch => no tags
> clone => no checkout
>
> In any case, "-n" has always a "no" meaning (even dry run, mean "no
> changes to be recorded").
>
> So IMHO -n is a really bad idea for "new"

Good point. I think I've changed my mind on that, but can't think of a good short flag for such a thing.

FWIW one reason this would be needed is that "switch" intentionally did not take "git switch unknown-name" to create "unknown-name", but maybe we could relax that if we just e.g. printed out a notice saying a new branch is created (which we probably do already...).

I.e. then the worst that'll happen is that the user has to "git switch -" and "git branch -d -", except I think the latter doesn't work, so "git branch -d <that-name>".

Show 14 quoted lines

> About "-b" branch:
> That does give no indication something is created. I find it highly
> confusing for checkout already,
> because the word "branch" could also mean "check out to existing
> branch" rather than doing a detached checkout.
> However, others may be perfectly fine with -b only referring to
> branches that will be created.
>
> -c of course is also used for config in clone.... :)
>
> If 2 letters could be used, then -c could be given twice for "create copy"
> -c  => create
> -c -c  => create copy
> -cc  => create copy

Hrm, that's interesting. But probably better to have a long-option. Some short options (notable -v for --verbose) often work like that, but I wonder if people wouldn't just be confused by it.

Maybe not.

Show 6 quoted lines

> ----------
> Also, will move/copy for switch actually be the same as for "git branch"?
>
> I haven't used them, but from the docs, I take it that a
> [new/replacement] branch will be created, and this branches tip points 
> to the same commit as the origin branch.

Both of them can take an optional "copy/create from". So I this is the same for both already, aside from one not supporting "copy".

Show 17 quoted lines

> But in "git switch" a new commit for the top is given. So that differs.
> Maybe someone can educate me ?
> - For move, where is the diff between
>   git switch --move existing_branch  commit
>   git switch --force-create existing_branch  commit
> Afaik only that the reflog will be copied/kept?
>
> For copy what does it mean at all?
>   git switch --copy existing_branch  commit
> Does not make any sense at all.
> Because "copy" means that "existing_branch" is to be kept. So copy
> needs a name for the new branch.
> I see 2 possible copies
>   git switch --copy existing_branch  new_branch commit
>   git switch --copy existing_branch  target_branch
> For the latter, it switches to the existing "target_branch", but
> replaces its reflog.

Maybe I'm being dense, but I'm not really seeing how a:

    git switch [some create option] <new> <old>

Would have caveats that we don't have already with:

    git branch [some create option] [<old>] <new>

Aside from the confusing switch-around of the arguments (which is another UX wart...).

Show 11 quoted lines

> Unless there is more, than the copying of the reflog, wouldn't it be
> better to add an option "--copy-reflog"
> Then you could do
> git switch --copy-reflog=branch   target_branch  # replace reflog of
> existing target branch
> git switch --copy-reflog=branch  -c new_branch  target_branch  #
> new_branch will get the reflog / this is "copy"
> git switch --copy-reflog=branch  -C new_branch  target_branch  #
> new_branch will get the reflog
> git switch --copy-reflog  -C existing_branch  target_branch  #
> existing_branch will keep the reflog. / this is "move"

Yes, I think "should it copy the reflog" is a thing that's arguably either a missing feature or a bug in the "git branch" copy mode, depending on your POV.