On Fri, Oct 22 2021, martin wrote:
> 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>".
> 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.
