From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: martin <test2@mfriebe.de>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org, Josh Steadmon <steadmon@google.com>
Subject: Re: changing the experimental 'git switch' (was: [Summit topic] Improving Git UX)
Date: Fri, 22 Oct 2021 16:24:49 +0200 [thread overview]
Message-ID: <211022.86v91pjfn7.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <9c6b3041-a5c0-6fe1-860e-7bfcb292ae81@mfriebe.de>
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.
next prev parent reply other threads:[~2021-10-22 14:30 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-21 11:55 Notes from the Git Contributors' Summit 2021, virtual, Oct 19/20 Johannes Schindelin
2021-10-21 11:55 ` [Summit topic] Crazy (and not so crazy) ideas Johannes Schindelin
2021-10-21 12:30 ` Son Luong Ngoc
2021-10-26 20:14 ` scripting speedups [was: [Summit topic] Crazy (and not so crazy) ideas] Eric Wong
2021-10-30 19:58 ` Ævar Arnfjörð Bjarmason
2021-11-03 9:24 ` test suite speedups via some not-so-crazy ideas (was: scripting speedups[...]) Ævar Arnfjörð Bjarmason
2021-11-03 22:12 ` test suite speedups via some not-so-crazy ideas Junio C Hamano
2021-11-02 13:52 ` scripting speedups [was: [Summit topic] Crazy (and not so crazy) ideas] Johannes Schindelin
2021-10-21 11:55 ` [Summit topic] SHA-256 Updates Johannes Schindelin
2021-10-21 11:56 ` [Summit topic] Server-side merge/rebase: needs and wants? Johannes Schindelin
2021-10-22 3:06 ` Bagas Sanjaya
2021-10-22 10:01 ` Johannes Schindelin
2021-10-23 20:52 ` Ævar Arnfjörð Bjarmason
2021-11-08 18:21 ` Taylor Blau
2021-11-09 2:15 ` Ævar Arnfjörð Bjarmason
2021-11-30 10:06 ` Christian Couder
2021-10-21 11:56 ` [Summit topic] Submodules and how to make them worth using Johannes Schindelin
2021-10-21 11:56 ` [Summit topic] Sparse checkout behavior and plans Johannes Schindelin
2021-10-21 11:56 ` [Summit topic] The state of getting a reftable backend working in git.git Johannes Schindelin
2021-10-25 19:00 ` Han-Wen Nienhuys
2021-10-25 22:09 ` Ævar Arnfjörð Bjarmason
2021-10-26 8:12 ` Han-Wen Nienhuys
2021-10-28 14:17 ` Philip Oakley
2021-10-26 15:51 ` Philip Oakley
2021-10-21 11:56 ` [Summit topic] Documentation (translations, FAQ updates, new user-focused, general improvements, etc.) Johannes Schindelin
2021-10-22 14:20 ` Jean-Noël Avila
2021-10-22 14:31 ` Ævar Arnfjörð Bjarmason
2021-10-27 7:02 ` Jean-Noël Avila
2021-10-27 8:50 ` Jeff King
2021-10-21 11:56 ` [Summit topic] Increasing diversity & inclusion (transition to `main`, etc) Johannes Schindelin
2021-10-21 12:55 ` Son Luong Ngoc
2021-10-22 10:02 ` vale check, was " Johannes Schindelin
2021-10-22 10:03 ` Johannes Schindelin
2021-10-21 11:57 ` [Summit topic] Improving Git UX Johannes Schindelin
2021-10-21 16:45 ` changing the experimental 'git switch' (was: [Summit topic] Improving Git UX) Ævar Arnfjörð Bjarmason
2021-10-21 23:03 ` changing the experimental 'git switch' Junio C Hamano
2021-10-22 3:33 ` changing the experimental 'git switch' (was: [Summit topic] Improving Git UX) Bagas Sanjaya
2021-10-22 14:04 ` martin
2021-10-22 14:24 ` Ævar Arnfjörð Bjarmason [this message]
2021-10-22 15:30 ` martin
2021-10-23 8:27 ` changing the experimental 'git switch' Sergey Organov
2021-10-22 21:54 ` Sergey Organov
2021-10-24 6:54 ` changing the experimental 'git switch' (was: [Summit topic] Improving Git UX) Martin
2021-10-24 20:27 ` changing the experimental 'git switch' Junio C Hamano
2021-10-25 12:48 ` Ævar Arnfjörð Bjarmason
2021-10-25 17:06 ` Junio C Hamano
2021-10-25 16:44 ` Sergey Organov
2021-10-25 22:23 ` Ævar Arnfjörð Bjarmason
2021-10-27 18:54 ` Sergey Organov
2021-10-21 11:57 ` [Summit topic] Improving reviewer quality of life (patchwork, subsystem lists?, etc) Johannes Schindelin
2021-10-21 13:41 ` Konstantin Ryabitsev
2021-10-22 22:06 ` Ævar Arnfjörð Bjarmason
2021-10-22 8:02 ` Missing notes, was Re: Notes from the Git Contributors' Summit 2021, virtual, Oct 19/20 Johannes Schindelin
2021-10-22 8:22 ` Johannes Schindelin
2021-10-22 8:30 ` Johannes Schindelin
2021-10-22 9:07 ` Johannes Schindelin
2021-10-22 9:44 ` Let's have public Git chalk talks, " Johannes Schindelin
2021-10-25 12:58 ` Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=211022.86v91pjfn7.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=steadmon@google.com \
--cc=test2@mfriebe.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).