From: Felipe Contreras <felipe.contreras@gmail.com>
To: Martin <git@mfriebe.de>,
Felipe Contreras <felipe.contreras@gmail.com>,
Sergey Organov <sorganov@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: PATCH: improve git switch documentation
Date: Fri, 09 Jul 2021 12:41:31 -0500 [thread overview]
Message-ID: <60e88a4b8592f_16bcb2082b@natae.notmuch> (raw)
In-Reply-To: <dbfa96f0-558e-ccaf-6e34-6d95c43848b5@mfriebe.de>
Martin wrote:
> On 09/07/2021 18:10, Felipe Contreras wrote:
> > Martin wrote:
> >> As for "git switch -C"
> >> This should IMHO change to (the 2nd arg, actually depends on the point
> >> "1" above)
> >> git switch (-c|-C) <branch-name> [<base-commit>]
> >>
> >> I suggest to not call it "new-branch-name" because, it might be an
> >> existing name.
> >
> > I think the name is all wrong. As Ævar pointed out --new (-n) is much
> > better. Also it doesn't make much sense to use "create" or "new" for
> > something that already exists.
>
> The n versus c issue is IMHO separate. Maybe tiny overlaps.
>
> I see it mostly in the light of -c should be for "copy".
>
> On "git checkout" it is "-b" for branch. That works, if you perceive
> "branch" as a verb. "The action of branching creates a new branch".
I generally view git commands as verbs. In this case "checkout" is the
verb, and "branch" is the direct object.
> Actually, "new" or "create" would make sense in "git branch". But in git
> switch, they actually raise the question "create what?" / "new what?".
`git switch` doesn't switch anything other branches. I don't think
`git switch-branch` would make the command somehow more understendale.
> > I think you saw a correct issue: `git switch -C` might be used
> > incorrectly, but changing to the documentation would have limited value
> > (and only for the ones that read it).
> >
> > I think if the branch already exists, the user has to be explicit to
> > what he wants to do and use `git switch --reset <branch> <commit>`
>
> Well, that is the question as what the action is perceived.
> I think the example is wrong, rather than the command.
>
> -c / -C /-n / -N always *c*reate an *n*ew branch. (create and new really
> are the same thing here)
>
> But if the branch name Foo, is already used?
> Well, it will still be a *new* branch being *created*.
> To do that it has to remove the name from the old branch. (effectively
> removing the old branch).
But it's not removing the name, it's merely changing the head.
I don't particularly mind having -C or -N, I just would not use them
because I like to be explicit. I don't use --new for something that
already exists.
> >> 3)
> >>
> >> newbbranch versus new-branch versus new_branch
> >>
> >> That is something that just needs to be decided.
> >> "new_branch" is in git checkout.
> >
> > I'd rather have <branch>, but as I already said, the more ground you try
> > to cover the more impossible it will be to actually land the changes.
>
> Well ok, if you shorten it to one word that solves it too.
> But for anything that for some reason needs two words, IMHO there should
> be one style. "one word", "-" or "_".
> Currently different styles are mixed.
I don't see the need for that, <new branch> would do the trick, no need
for hyphens or underscores.
> >> Look at
> >> git checkout --force
> >>> --force
> >>> When switching branches, proceed even if the index or the working tree differs from HEAD. This is used to throw away local changes.
> >>
> >
> > All these issues go away if we have:
> >
> > git switch --reset <branch> <commit>
> >
> > And instead of -C, we have:
> >
> > git switch --new --reset <branch> <commit>
> >
> > This creates a new branch if it doesn't exist, or if it exists resets
> > it.
>
> Nope it does not go away.
>
> All this has done, is that it no longer is a "force" command.
> So the last bit of warning has just gone.
>
> And it still needs to be documented inside the "git switch" doc, rather
> than forwarding the user do yet another doc.
Yes, but as I said: the documentation writes itself.
-n <branch>, --new <branch>
Creates a new branch.
--reset <branch>
Resets the branch to <head>.
> Also making the user read the "git reset" doc does not help, unless we
> point out that this is a --hard reset, rather than "modifying the index".
Nobody is suggesting that. --reset refers to the English word "reset",
not `get reset`.
> So, I still ask:
> - If "--force" to overwrite the work tree can clearly state that change
> to files will be "thrown away".
> - Then why can "force" re-using an existing branch name not do the same?
Because we would be forcing two things now. I'd rather not overload
concepts.
Cheers.
--
Felipe Contreras
next prev parent reply other threads:[~2021-07-09 17:41 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-29 15:28 PATCH: improve git switch documentation Martin
2021-06-29 16:35 ` Junio C Hamano
2021-06-29 19:04 ` Martin
2021-06-29 22:39 ` Junio C Hamano
2021-06-30 8:50 ` Martin
2021-06-30 22:59 ` Junio C Hamano
2021-07-01 10:06 ` Martin
2021-07-01 11:27 ` Sergey Organov
2021-07-07 18:34 ` Felipe Contreras
2021-07-07 20:46 ` Sergey Organov
2021-07-07 21:25 ` What actually is a branch? Felipe Contreras
2021-07-07 22:07 ` Sergey Organov
2021-07-07 22:35 ` Martin
2021-07-08 3:39 ` Felipe Contreras
2021-07-08 10:15 ` Martin
2021-07-08 17:33 ` Felipe Contreras
2021-07-08 19:21 ` Martin
2021-07-08 20:37 ` Felipe Contreras
2021-07-08 23:11 ` Martin
2021-07-09 0:45 ` Felipe Contreras
2021-07-09 13:24 ` Martin
2021-07-09 15:08 ` Felipe Contreras
2021-07-09 15:23 ` switch requires --detach [[Re: What actually is a branch]] Martin
2021-07-09 16:21 ` Felipe Contreras
2021-07-09 16:38 ` Randall S. Becker
2021-07-09 17:10 ` Felipe Contreras
2021-07-09 16:54 ` Martin
2021-07-10 10:08 ` Sergey Organov
2021-07-10 19:18 ` Felipe Contreras
2021-07-09 14:29 ` PATCH: improve git switch documentation Martin
2021-07-09 16:10 ` Felipe Contreras
2021-07-09 16:51 ` Martin
2021-07-09 17:41 ` Felipe Contreras [this message]
2021-07-09 18:23 ` Martin
2021-07-10 19:45 ` Felipe Contreras
2021-07-10 20:07 ` Martin
2021-07-10 20:49 ` Felipe Contreras
2021-07-10 22:13 ` Martin
2021-07-10 23:35 ` Felipe Contreras
2021-07-11 9:10 ` Martin
2021-07-11 9:30 ` Sergey Organov
2021-07-12 16:28 ` Felipe Contreras
2021-07-12 16:33 ` Martin
2021-07-12 16:58 ` Felipe Contreras
2021-07-12 17:52 ` Martin
2021-07-12 19:08 ` Felipe Contreras
[not found] ` <3a84e4c9-4e48-1cbe-4fe6-150ff56c8508@mfriebe.de>
[not found] ` <60ecbe577a086_a6b702082@natae.notmuch>
2021-07-13 10:42 ` Martin
2021-07-13 16:02 ` Felipe Contreras
2021-07-16 18:12 ` Martin
2021-07-16 18:31 ` Martin
2021-07-16 18:56 ` Felipe Contreras
2021-07-17 7:02 ` Martin
[not found] ` <1997ca3b-117a-e19a-0dee-7342a2f1a0e7@mfriebe.de>
[not found] ` <60f1f4c3dd8b1_14cb208c1@natae.notmuch>
[not found] ` <fedbfe1f-9e6d-f46f-ca41-e176a30e938c@mfriebe.de>
[not found] ` <60f22aaa6a4f1_1f602081b@natae.notmuch>
2021-07-17 10:07 ` Martin
[not found] ` <60f33f8a7c39b_507220823@natae.notmuch>
2021-07-17 21:23 ` Martin
2021-07-19 17:51 ` Felipe Contreras
2021-07-11 7:57 ` Sergey Organov
2021-07-11 9:27 ` Martin
2021-07-11 9:37 ` Sergey Organov
2021-07-11 10:24 ` Martin
2021-07-12 16:34 ` Felipe Contreras
2021-07-10 22:13 ` Naming the --forec option [[Re: PATCH: improve git switch documentation]] Martin
2021-07-10 23:18 ` Felipe Contreras
2021-07-11 0:39 ` Martin
2021-07-12 16:15 ` Felipe Contreras
2021-07-10 10:24 ` PATCH: improve git switch documentation Sergey Organov
2021-07-10 10:37 ` Bagas Sanjaya
2021-07-10 11:05 ` Martin
2021-07-10 16:32 ` Sergey Organov
2021-07-10 20:12 ` Felipe Contreras
2021-07-11 9:04 ` Sergey Organov
2021-07-11 10:05 ` Martin
2021-07-11 12:23 ` Sergey Organov
2021-07-11 13:39 ` Martin
2021-07-11 14:49 ` Sergey Organov
2021-07-11 16:51 ` Sergey Organov
2021-07-12 10:31 ` Kerry, Richard
2021-07-12 11:11 ` Sergey Organov
2021-07-12 16:55 ` Felipe Contreras
2021-07-12 16:24 ` Felipe Contreras
2021-07-12 16:39 ` Martin
2021-07-12 17:09 ` Felipe Contreras
2021-07-12 22:58 ` Sergey Organov
2021-07-12 23:36 ` Felipe Contreras
2021-07-13 11:20 ` Martin
2021-07-10 20:00 ` Felipe Contreras
2021-07-10 19:51 ` Felipe Contreras
2021-07-11 9:52 ` Sergey Organov
2021-07-12 16:44 ` Felipe Contreras
2021-07-13 10:57 ` Sergey Organov
2021-07-13 16:10 ` Felipe Contreras
2021-07-14 19:14 ` Sergey Organov
2021-07-14 19:51 ` Felipe Contreras
2021-07-14 20:42 ` Sergey Organov
2021-07-08 3:12 ` What actually is a branch? Felipe Contreras
2021-07-08 11:16 ` Sergey Organov
2021-07-08 18:05 ` Felipe Contreras
2021-07-01 14:58 ` PATCH: improve git switch documentation Junio C Hamano
2021-07-01 17:29 ` Martin
2021-07-01 17:46 ` Sergey Organov
2021-07-07 18:54 ` Felipe Contreras
2021-07-07 18:47 ` Felipe Contreras
2021-07-07 18:14 ` Felipe Contreras
2021-07-01 0:06 ` Matt Rogers
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60e88a4b8592f_16bcb2082b@natae.notmuch \
--to=felipe.contreras@gmail.com \
--cc=git@mfriebe.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sorganov@gmail.com \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.