From: "Christoph Michelbach" <michelbach94@xxxxxxxxx>
While technically in the documentation, the fact that changes
introduced by a checkout <tree-ish> are staged automatically, was
not obvious when reading its documentation. It is now specifically
pointed out.
Signed-off-by: Christoph Michelbach <michelbach94@xxxxxxxxx>
---
Documentation/git-checkout.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-checkout.txt
b/Documentation/git-checkout.txt
index 8e2c066..cfd7b18 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -85,9 +85,10 @@ Omitting <branch> detaches HEAD at the tip of the
current branch.
from the index file or from a named <tree-ish> (most often a
commit). In this case, the `-b` and `--track` options are
meaningless and giving either of them results in an error. The
- <tree-ish> argument can be used to specify a specific tree-ish
- (i.e. commit, tag or tree) to update the index for the given
Do these lines above actually need reflowing? Their content hasn't changed
making it more difficult to spot the significant changes below here.
- paths before updating the working tree.
+ <tree-ish> argument can be used to specify the tree-ish (i.e.
+ commit, tag, or tree) to update the index to for the given paths
+ before updating the working tree accordingly.
+ Note that this means
+ that the changes this command introduces are staged automatically.
Does this actually capture the intent of the user confusion it's meant to
cover? I may have missed the original discussions.
For a clean commit checkout my mental model is not one of anything new being
actively staged i.e. different from what was in the commit. I can see that
if a particular tree is checkout then it's implicit staging could well be a
surprise.
I am in favour of improving the documentation to avoid user surprise
+
'git checkout' with <paths> or `--patch` is used to restore modified or
deleted paths to their original contents from the index or replace paths
--
2.7.4
--
Philip