Re: changing the experimental 'git switch' (was: [Summit topic] Improving Git UX)
flat view
From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-10-22 14:30:42
On Fri, Oct 22 2021, martin wrote:
On 21/10/2021 18:45, Ævar Arnfjörð Bjarmason wrote:quoted
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>".
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.
---------- 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".
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...).
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.