The new command "git switch" is added to avoid the confusion of
one-command-do-all "git checkout" for new users. They are also helpful
to avoid ambiguation context.

For these reasons, promote it everywhere possible. This includes
documentation, suggestions/advice from other commands...

The "Checking out files" progress line in unpack-trees.c is also updated
to "Updating files" to be neutral to both git-checkout and git-switch.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Nguyễn Thái Ngọc Duy 2019-03-29 17:39:19 +07:00 коммит произвёл Junio C Hamano
Родитель ae36fe6941
Коммит 328c6cb853
19 изменённых файлов: 105 добавлений и 105 удалений

Просмотреть файл

@ -48,7 +48,7 @@ The command's second form creates a new branch head named <branchname>
which points to the current `HEAD`, or <start-point> if given.
Note that this will create the new branch, but it will not switch the
working tree to it; use "git checkout <newbranch>" to switch to the
working tree to it; use "git switch <newbranch>" to switch to the
new branch.
When a local branch is started off a remote-tracking branch, Git sets up the
@ -198,7 +198,7 @@ This option is only applicable in non-verbose mode.
+
This behavior is the default when the start point is a remote-tracking branch.
Set the branch.autoSetupMerge configuration variable to `false` if you
want `git checkout` and `git branch` to always behave as if `--no-track`
want `git switch`, `git checkout` and `git branch` to always behave as if `--no-track`
were given. Set it to `always` if you want this behavior when the
start-point is either a local or remote-tracking branch.
@ -297,7 +297,7 @@ Start development from a known tag::
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
$ cd my2.6
$ git branch my2.6.14 v2.6.14 <1>
$ git checkout my2.6.14
$ git switch my2.6.14
------------
+
<1> This step and the next one could be combined into a single step with
@ -322,9 +322,9 @@ $ git branch -D test <2>
NOTES
-----
If you are creating a branch that you want to checkout immediately, it is
easier to use the git checkout command with its `-b` option to create
a branch and check it out with a single command.
If you are creating a branch that you want to switch to immediately,
it is easier to use the "git switch" command with its `-c` option to
do the same thing with a single command.
The options `--contains`, `--no-contains`, `--merged` and `--no-merged`
serve four related but different purposes:

Просмотреть файл

@ -88,7 +88,8 @@ but it is explicitly forbidden at the beginning of a branch name).
When run with `--branch` option in a repository, the input is first
expanded for the ``previous checkout syntax''
`@{-n}`. For example, `@{-1}` is a way to refer the last thing that
was checked out using "git checkout" operation. This option should be
was checked out using "git switch" or "git checkout" operation.
This option should be
used by porcelains to accept this syntax anywhere a branch name is
expected, so they can act as if you typed the branch name. As an
exception note that, the ``previous checkout operation'' might result

Просмотреть файл

@ -421,7 +421,7 @@ One way to test if your MUA is set up correctly is:
* Apply it:
$ git fetch <project> master:test-apply
$ git checkout test-apply
$ git switch test-apply
$ git reset --hard
$ git am a.patch

Просмотреть файл

@ -149,7 +149,7 @@ instead.
Discussion on fork-point mode
-----------------------------
After working on the `topic` branch created with `git checkout -b
After working on the `topic` branch created with `git switch -c
topic origin/master`, the history of remote-tracking branch
`origin/master` may have been rewound and rebuilt, leading to a
history of this shape:

Просмотреть файл

@ -17,7 +17,7 @@ SYNOPSIS
DESCRIPTION
-----------
If <branch> is specified, 'git rebase' will perform an automatic
`git checkout <branch>` before doing anything else. Otherwise
`git switch <branch>` before doing anything else. Otherwise
it remains on the current branch.
If <upstream> is not specified, the upstream configured in

Просмотреть файл

@ -230,7 +230,7 @@ $ git branch -r
staging/master
staging/staging-linus
staging/staging-next
$ git checkout -b staging staging/master
$ git switch -c staging staging/master
...
------------

Просмотреть файл

@ -91,7 +91,7 @@ For such a test, you need to merge master and topic somehow.
One way to do it is to pull master into the topic branch:
------------
$ git checkout topic
$ git switch topic
$ git merge master
o---*---o---+ topic
@ -113,10 +113,10 @@ the upstream might have been advanced since the test merge `+`,
in which case the final commit graph would look like this:
------------
$ git checkout topic
$ git switch topic
$ git merge master
$ ... work on both topic and master branches
$ git checkout master
$ git switch master
$ git merge topic
o---*---o---+---o---o topic
@ -136,11 +136,11 @@ merges, you could blow away the test merge, and keep building on
top of the tip before the test merge:
------------
$ git checkout topic
$ git switch topic
$ git merge master
$ git reset --hard HEAD^ ;# rewind the test merge
$ ... work on both topic and master branches
$ git checkout master
$ git switch master
$ git merge topic
o---*---o-------o---o topic

Просмотреть файл

@ -151,7 +151,7 @@ Undo a commit, making it a topic branch::
------------
$ git branch topic/wip <1>
$ git reset --hard HEAD~3 <2>
$ git checkout topic/wip <3>
$ git switch topic/wip <3>
------------
+
<1> You have made some commits, but realize they were premature
@ -232,13 +232,13 @@ working tree are not in any shape to be committed yet, but you
need to get to the other branch for a quick bugfix.
+
------------
$ git checkout feature ;# you were working in "feature" branch and
$ git switch feature ;# you were working in "feature" branch and
$ work work work ;# got interrupted
$ git commit -a -m "snapshot WIP" <1>
$ git checkout master
$ git switch master
$ fix fix fix
$ git commit ;# commit with real log
$ git checkout feature
$ git switch feature
$ git reset --soft HEAD^ ;# go back to WIP state <2>
$ git reset <3>
------------
@ -279,18 +279,18 @@ reset it while keeping the changes in your working tree.
+
------------
$ git tag start
$ git checkout -b branch1
$ git switch -c branch1
$ edit
$ git commit ... <1>
$ edit
$ git checkout -b branch2 <2>
$ git switch -c branch2 <2>
$ git reset --keep start <3>
------------
+
<1> This commits your first edits in `branch1`.
<2> In the ideal world, you could have realized that the earlier
commit did not belong to the new topic when you created and switched
to `branch2` (i.e. `git checkout -b branch2 start`), but nobody is
to `branch2` (i.e. `git switch -c branch2 start`), but nobody is
perfect.
<3> But you can use `reset --keep` to remove the unwanted commit after
you switched to `branch2`.

Просмотреть файл

@ -235,12 +235,12 @@ return to your original branch to make the emergency fix, like this:
+
----------------------------------------------------------------
# ... hack hack hack ...
$ git checkout -b my_wip
$ git switch -c my_wip
$ git commit -a -m "WIP"
$ git checkout master
$ git switch master
$ edit emergency fix
$ git commit -a -m "Fix in a hurry"
$ git checkout my_wip
$ git switch my_wip
$ git reset --soft HEAD^
# ... continue hacking ...
----------------------------------------------------------------
@ -293,7 +293,8 @@ SEE ALSO
linkgit:git-checkout[1],
linkgit:git-commit[1],
linkgit:git-reflog[1],
linkgit:git-reset[1]
linkgit:git-reset[1],
linkgit:git-switch[1]
GIT
---

Просмотреть файл

@ -741,7 +741,7 @@ used earlier, and create a branch in it. You do that by simply just
saying that you want to check out a new branch:
------------
$ git checkout -b mybranch
$ git switch -c mybranch
------------
will create a new branch based at the current `HEAD` position, and switch
@ -755,7 +755,7 @@ just telling 'git checkout' what the base of the checkout would be.
In other words, if you have an earlier tag or branch, you'd just do
------------
$ git checkout -b mybranch earlier-commit
$ git switch -c mybranch earlier-commit
------------
and it would create the new branch `mybranch` at the earlier commit,
@ -765,7 +765,7 @@ and check out the state at that time.
You can always just jump back to your original `master` branch by doing
------------
$ git checkout master
$ git switch master
------------
(or any other branch-name, for that matter) and if you forget which
@ -794,7 +794,7 @@ $ git branch <branchname> [startingpoint]
which will simply _create_ the branch, but will not do anything further.
You can then later -- once you decide that you want to actually develop
on that branch -- switch to that branch with a regular 'git checkout'
on that branch -- switch to that branch with a regular 'git switch'
with the branchname as the argument.
@ -808,7 +808,7 @@ being the same as the original `master` branch, let's make sure we're in
that branch, and do some work there.
------------------------------------------------
$ git checkout mybranch
$ git switch mybranch
$ echo "Work, work, work" >>hello
$ git commit -m "Some work." -i hello
------------------------------------------------
@ -825,7 +825,7 @@ does some work in the original branch, and simulate that by going back
to the master branch, and editing the same file differently there:
------------
$ git checkout master
$ git switch master
------------
Here, take a moment to look at the contents of `hello`, and notice how they
@ -958,7 +958,7 @@ to the `master` branch. Let's go back to `mybranch`, and run
'git merge' to get the "upstream changes" back to your branch.
------------
$ git checkout mybranch
$ git switch mybranch
$ git merge -m "Merge upstream changes." master
------------
@ -1133,9 +1133,8 @@ Remember, before running 'git merge', our `master` head was at
work." commit.
------------
$ git checkout mybranch
$ git reset --hard master^2
$ git checkout master
$ git switch -C mybranch master^2
$ git switch master
$ git reset --hard master^
------------

Просмотреть файл

@ -41,7 +41,7 @@ following commands.
* linkgit:git-log[1] to see what happened.
* linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
* linkgit:git-switch[1] and linkgit:git-branch[1] to switch
branches.
* linkgit:git-add[1] to manage the index file.
@ -80,7 +80,7 @@ $ git tag v2.43 <2>
Create a topic branch and develop.::
+
------------
$ git checkout -b alsa-audio <1>
$ git switch -c alsa-audio <1>
$ edit/compile/test
$ git checkout -- curses/ux_audio_oss.c <2>
$ git add curses/ux_audio_alsa.c <3>
@ -90,7 +90,7 @@ $ git commit -a -s <5>
$ edit/compile/test
$ git diff HEAD^ <6>
$ git commit -a --amend <7>
$ git checkout master <8>
$ git switch master <8>
$ git merge alsa-audio <9>
$ git log --since='3 days ago' <10>
$ git log v2.43.. curses/ <11>
@ -148,11 +148,11 @@ Clone the upstream and work on it. Feed changes to upstream.::
------------
$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
$ cd my2.6
$ git checkout -b mine master <1>
$ git switch -c mine master <1>
$ edit/compile/test; git commit -a -s <2>
$ git format-patch master <3>
$ git send-email --to="person <email@example.com>" 00*.patch <4>
$ git checkout master <5>
$ git switch master <5>
$ git pull <6>
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <7>
$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git <8>
@ -194,7 +194,7 @@ satellite$ edit/compile/test/commit
satellite$ git push origin <4>
mothership$ cd frotz
mothership$ git checkout master
mothership$ git switch master
mothership$ git merge satellite/master <5>
------------
+
@ -216,7 +216,7 @@ machine into the master branch.
Branch off of a specific tag.::
+
------------
$ git checkout -b private2.6.14 v2.6.14 <1>
$ git switch -c private2.6.14 v2.6.14 <1>
$ edit/compile/test; git commit -a
$ git checkout master
$ git cherry-pick v2.6.14..private2.6.14 <2>
@ -274,14 +274,14 @@ $ mailx <3>
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
$ git checkout -b topic/one master
$ git switch -c topic/one master
$ git am -3 -i -s ./+to-apply <4>
$ compile/test
$ git checkout -b hold/linus && git am -3 -i -s ./+hold-linus <5>
$ git checkout topic/one && git rebase master <6>
$ git checkout pu && git reset --hard next <7>
$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5>
$ git switch topic/one && git rebase master <6>
$ git switch -C pu next <7>
$ git merge topic/one topic/two && git merge hold/linus <8>
$ git checkout maint
$ git switch maint
$ git cherry-pick master~4 <9>
$ compile/test
$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>

Просмотреть файл

@ -207,7 +207,7 @@ automatically. The asterisk marks the branch you are currently on;
type
------------------------------------------------
$ git checkout experimental
$ git switch experimental
------------------------------------------------
to switch to the experimental branch. Now edit a file, commit the
@ -216,7 +216,7 @@ change, and switch back to the master branch:
------------------------------------------------
(edit file)
$ git commit -a
$ git checkout master
$ git switch master
------------------------------------------------
Check that the change you made is no longer visible, since it was

Просмотреть файл

@ -301,8 +301,7 @@ topics on 'next':
.Rewind and rebuild next
[caption="Recipe: "]
=====================================
* `git checkout next`
* `git reset --hard master`
* `git switch -C next master`
* `git merge ai/topic_in_next1`
* `git merge ai/topic_in_next2`
* ...

Просмотреть файл

@ -115,7 +115,7 @@ Here's an example to make it more clear:
------------------------------
$ git config push.default current
$ git config remote.pushdefault myfork
$ git checkout -b mybranch origin/master
$ git switch -c mybranch origin/master
$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master

Просмотреть файл

@ -122,10 +122,10 @@ Tags are expected to always point at the same version of a project,
while heads are expected to advance as development progresses.
Create a new branch head pointing to one of these versions and check it
out using linkgit:git-checkout[1]:
out using linkgit:git-switch[1]:
------------------------------------------------
$ git checkout -b new v2.6.13
$ git switch -c new v2.6.13
------------------------------------------------
The working directory then reflects the contents that the project had
@ -282,10 +282,10 @@ a summary of the commands:
this command will fail with a warning.
`git branch -D <branch>`::
delete the branch `<branch>` irrespective of its merged status.
`git checkout <branch>`::
`git switch <branch>`::
make the current branch `<branch>`, updating the working
directory to reflect the version referenced by `<branch>`.
`git checkout -b <new> <start-point>`::
`git switch -c <new> <start-point>`::
create a new branch `<new>` referencing `<start-point>`, and
check it out.
@ -302,22 +302,22 @@ ref: refs/heads/master
Examining an old version without creating a new branch
------------------------------------------------------
The `git checkout` command normally expects a branch head, but will also
accept an arbitrary commit; for example, you can check out the commit
referenced by a tag:
The `git switch` command normally expects a branch head, but will also
accept an arbitrary commit when invoked with --detach; for example,
you can check out the commit referenced by a tag:
------------------------------------------------
$ git checkout v2.6.17
$ git switch --detach v2.6.17
Note: checking out 'v2.6.17'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
state without impacting any branches by performing another switch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
do so (now or later) by using -c with the switch command again. Example:
git checkout -b new_branch_name
git switch -c new_branch_name
HEAD is now at 427abfa Linux v2.6.17
------------------------------------------------
@ -373,7 +373,7 @@ You might want to build on one of these remote-tracking branches
on a branch of your own, just as you would for a tag:
------------------------------------------------
$ git checkout -b my-todo-copy origin/todo
$ git switch -c my-todo-copy origin/todo
------------------------------------------------
You can also check out `origin/todo` directly to examine it or
@ -2211,8 +2211,8 @@ $ git branch --track release origin/master
These can be easily kept up to date using linkgit:git-pull[1].
-------------------------------------------------
$ git checkout test && git pull
$ git checkout release && git pull
$ git switch test && git pull
$ git switch release && git pull
-------------------------------------------------
Important note! If you have any local changes in these branches, then
@ -2264,7 +2264,7 @@ tested changes
2) help future bug hunters that use `git bisect` to find problems
-------------------------------------------------
$ git checkout -b speed-up-spinlocks v2.6.35
$ git switch -c speed-up-spinlocks v2.6.35
-------------------------------------------------
Now you apply the patch(es), run some tests, and commit the change(s). If
@ -2279,7 +2279,7 @@ When you are happy with the state of this change, you can merge it into the
"test" branch in preparation to make it public:
-------------------------------------------------
$ git checkout test && git merge speed-up-spinlocks
$ git switch test && git merge speed-up-spinlocks
-------------------------------------------------
It is unlikely that you would have any conflicts here ... but you might if you
@ -2291,7 +2291,7 @@ see the value of keeping each patch (or patch series) in its own branch. It
means that the patches can be moved into the `release` tree in any order.
-------------------------------------------------
$ git checkout release && git merge speed-up-spinlocks
$ git switch release && git merge speed-up-spinlocks
-------------------------------------------------
After a while, you will have a number of branches, and despite the
@ -2512,7 +2512,7 @@ Suppose that you create a branch `mywork` on a remote-tracking branch
`origin`, and create some commits on top of it:
-------------------------------------------------
$ git checkout -b mywork origin
$ git switch -c mywork origin
$ vi file.txt
$ git commit
$ vi otherfile.txt
@ -2552,7 +2552,7 @@ commits without any merges, you may instead choose to use
linkgit:git-rebase[1]:
-------------------------------------------------
$ git checkout mywork
$ git switch mywork
$ git rebase origin
-------------------------------------------------
@ -3668,13 +3668,13 @@ change within the submodule, and then update the superproject to reference the
new commit:
-------------------------------------------------
$ git checkout master
$ git switch master
-------------------------------------------------
or
-------------------------------------------------
$ git checkout -b fix-up
$ git switch -c fix-up
-------------------------------------------------
then
@ -4194,7 +4194,7 @@ start.
A good place to start is with the contents of the initial commit, with:
----------------------------------------------------
$ git checkout e83c5163
$ git switch --detach e83c5163
----------------------------------------------------
The initial revision lays the foundation for almost everything Git has
@ -4438,7 +4438,7 @@ Managing branches
-----------------------------------------------
$ git branch # list all local branches in this repo
$ git checkout test # switch working directory to branch "test"
$ git switch test # switch working directory to branch "test"
$ git branch new # create branch "new" starting at current HEAD
$ git branch -d new # delete branch "new"
-----------------------------------------------
@ -4456,7 +4456,7 @@ $ git branch new test~10 # ten commits before tip of branch "test"
Create and switch to a new branch at the same time:
-----------------------------------------------
$ git checkout -b new v2.6.15
$ git switch -c new v2.6.15
-----------------------------------------------
Update and examine branches from the repository you cloned from:
@ -4467,7 +4467,7 @@ $ git branch -r # list
origin/master
origin/next
...
$ git checkout -b masterwork origin/master
$ git switch -c masterwork origin/master
-----------------------------------------------
Fetch a branch from a different repository, and give it a new

Просмотреть файл

@ -191,20 +191,20 @@ void NORETURN die_conclude_merge(void)
void detach_advice(const char *new_name)
{
const char *fmt =
_("Note: checking out '%s'.\n"
_("Note: switching to '%s'.\n"
"\n"
"You are in 'detached HEAD' state. You can look around, make experimental\n"
"changes and commit them, and you can discard any commits you make in this\n"
"state without impacting any branches by performing another checkout.\n"
"state without impacting any branches by switching back to a branch.\n"
"\n"
"If you want to create a new branch to retain commits you create, you may\n"
"do so (now or later) by using -b with the checkout command again. Example:\n"
"do so (now or later) by using -c with the switch command. Example:\n"
"\n"
" git checkout -b <new-branch-name>\n"
" git switch -c <new-branch-name>\n"
"\n"
"Or undo this checkout with:\n"
"Or undo this operation with:\n"
"\n"
" git checkout -\n"
" git switch -\n"
"\n"
"Turn off this advice by setting config variable advice.detachedHead to false\n\n");

Просмотреть файл

@ -743,7 +743,7 @@ static int get_oid_basic(const char *str, int len, struct object_id *oid,
"because it will be ignored when you just specify 40-hex. These refs\n"
"may be created by mistake. For example,\n"
"\n"
" git checkout -b $br $(git rev-parse ...)\n"
" git switch -c $br $(git rev-parse ...)\n"
"\n"
"where \"$br\" is somehow empty and a 40-hex ref is created. Please\n"
"examine these refs and maybe delete them. Turn this message off by\n"

Просмотреть файл

@ -195,20 +195,20 @@ test_expect_success 'describe_detached_head prints no SHA-1 ellipsis when not as
# The first detach operation is more chatty than the following ones.
cat >1st_detach <<-EOF &&
Note: checking out 'HEAD^'.
Note: switching to 'HEAD^'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
do so (now or later) by using -c with the switch command. Example:
git checkout -b <new-branch-name>
git switch -c <new-branch-name>
Or undo this checkout with:
Or undo this operation with:
git checkout -
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
@ -277,20 +277,20 @@ test_expect_success 'describe_detached_head does print SHA-1 ellipsis when asked
# The first detach operation is more chatty than the following ones.
cat >1st_detach <<-EOF &&
Note: checking out 'HEAD^'.
Note: switching to 'HEAD^'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
do so (now or later) by using -c with the switch command. Example:
git checkout -b <new-branch-name>
git switch -c <new-branch-name>
Or undo this checkout with:
Or undo this operation with:
git checkout -
git switch -
Turn off this advice by setting config variable advice.detachedHead to false

Просмотреть файл

@ -313,7 +313,7 @@ static struct progress *get_progress(struct unpack_trees_options *o)
total++;
}
return start_delayed_progress(_("Checking out files"), total);
return start_delayed_progress(_("Updating files"), total);
}
static void setup_collided_checkout_detection(struct checkout *state,