switch: add --ensure option#2324
Conversation
Welcome to GitGitGadgetHi @Korov, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that either:
You can CC potential reviewers by adding a footer to the PR description with the following syntax: NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description, Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail). If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txtTo iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description): To send a new iteration, just add another PR comment with the contents: Need help?New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join. You may also be able to find help in real time in the developer IRC channel, |
|
There is an issue in commit 7e48ee7:
|
Add a new `git switch --ensure` (`-e`) option that behaves like an idempotent form of branch switching. Users who often switch between topic branches may not know whether the local branch already exists. Without this option, they need to check for the branch first and then choose between `git switch <branch>` and `git switch -c <branch>`. The new option folds that workflow into a single command. When the target branch does not exist, `git switch -e <branch>` behaves like `git switch -c <branch>`, including existing `--track` and `--no-track` handling. When the target branch already exists, `git switch -e <branch>` switches to it without resetting the branch tip. If `--track` is given, update the branch's upstream configuration using the explicit start-point, or the current branch when no start-point is provided. Fail in detached HEAD state when no start-point is available for tracking setup. Document the new option and add tests covering create-branch tracking, existing-branch tracking updates, and detached-HEAD failure cases. Signed-off-by: Korov <korov9.c@gmail.com>
|
/allow |
|
User Korov is now allowed to use GitGitGadget. WARNING: Korov has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use. |
|
/submit |
|
Submitted as pull.2324.git.git.1780997009796.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): "Lei Zhu via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Users who often switch between topic branches may not know whether the
> local branch already exists. Without this option, they need to check
> for the branch first and then choose between `git switch <branch>` and
> `git switch -c <branch>`. The new option folds that workflow into a
> single command.
Quite honestly, I am not sure if the use case should be supported
with a new option, or we should actively discourage it by rejecting
any patch that takes us in this direction, as the actions the user
would take after seeing the result of "git checkout -b" or "git
switch -c" are quite different among (just off the top of my head):
(1) Ah we already had the branch created exactly to work on this;
instead of forking a new effort, switch to the existing branch
and build on the effort we made previously, as it forks from an
acceptable base, which might have been different from where we
wanted to start at when we said "git switch -c <branch> <base>".
(2) Ah we already had the branch created exactly to work on this.
Unfortunately, it was forked from way too new base before we
realized that this is also an important bugfix that needs to be
mergeable to the maintenance track. Let's create a new branch
that is a copy of the existing one with "-maint" in its name,
rebase it on the maintenance track, and work there.
(3) Ah we already had a branch that happened to have the same name,
but created for totally different reasons. We do want to fork
a new branch but need to give it a different name.
(4) There wasn't a branch with the given name, so we created a new
branch at the right starting point we just picked when we ran
"git checkout -b"/"git switch -c". Let's start working on the
topic.
You cover *only* case (4) perfectly. When your "-c <branch>" picks
an existing branch, the user still needs to figure out which among
situations (1)-(3) (of course, there may be others) they are in, and
act accordingly. "git checkout -b" and "git switch -c" that fails,
reminding that there is an existing branch with the same name, gives
users a stronger form of reminder than switching blindly to the
existing branch, which may (in case (1)) or may not (in cases (2)
and (3)) be where the user wants to be when taking the next action.
Having said that.
* The option name "-e" would make all users expect that this has
something to do with "--editor". Start with a longer name,
perhaps "--create-if-missing" or something, and then see if
others can come up with a better short-hand. Obviously whoever
chooses "-e" is not equipped well to do so (yet), and the
reviewer who pointed out "-e" is not a good idea without being
able to offer a better alternative is not, either ;-).
* Adding a new flag only to "switch" without "checkout" will
unnecessary confuse users. This is because, even though
"switch/restore" started as an experiment to _supersede_
"checkout", they were not successful, not in the sense that
"switch/restore" were harder to use than the original, but in the
sense that the userbase and teaching materials are already used
to the original and removing it is practically infeasible. |
Add a new
git switch --ensure(-e) option that behaves like an idempotent form of branch switching.Users who often switch between topic branches may not know whether the local branch already exists. Without this option, they need to check for the branch first and then choose between
git switch <branch>andgit switch -c <branch>. The new option folds that workflow into a single command.When the target branch does not exist,
git switch -e <branch>behaves likegit switch -c <branch>, including existing--trackand--no-trackhandling.When the target branch already exists,
git switch -e <branch>switches to it without resetting the branch tip. If--trackis given, update the branch's upstream configuration using the explicit start-point, or the current branch when no start-point is provided. Fail in detached HEAD state when no start-point is available for tracking setup.Document the new option and add tests covering create-branch tracking, existing-branch tracking updates, and detached-HEAD failure cases.
Thanks for taking the time to contribute to Git! Please be advised that the
Git community does not use github.com for their contributions. Instead, we use
a mailing list (git@vger.kernel.org) for code submissions, code reviews, and
bug reports. Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/)
to conveniently send your Pull Requests commits to our mailing list.
For a single-commit pull request, please leave the pull request description
empty: your commit message itself should describe your changes.
Please read the "guidelines for contributing" linked above!