Which is the role of "git checkout <branch>"
"git checkout <branch> <paths>" is similar to "hg revert -r <branch> <paths>",
No it is not.
The form of the command is makes this request:
Please look into that named <tree-ish>, and check out the named
<paths> out of it to my work tree. Because the reason I want them in
my work tree is so that I can include them as part of the next commit
I am preparing to create in the index, please update these paths in my
index while at it.
After working for some time on top of the current HEAD to make changes to
existing files in "lib/" directory, if you notice that none of your
changes in the directory does not make any sense, you may rather want to
start over from the version that you began with. In such a case, you
would make the above request with <tree-ish> equal to HEAD and <paths>
equal to "lib", i.e.
git checkout HEAD lib
and as the end result you may be able to achieve "reverting my crappy
changes to all of the files in lib/".
HOWEVER.
Read what the above request says carefully again, and think about what
would happen to a path that exists in the work tree but not in the named
<tree-ish>.
In other words, what would happen to a new file you added since you
started working on top of HEAD?
See?
A new file that you added in lib/ directory since you started working will
not be molested in any way, because they do not even exist in the
<tree-ish>.
If you think "git checkout <tree-ish> <paths>" has anything to do with
reverting, you will keep confusing yourself. The command is "checking out
the named paths out of the named tree", and absense of a file is not
something that is checked out by this operation.
Which is the role of "git checkout <branch>"
"git checkout <branch> <paths>" is similar to "hg revert -r <branch> <paths>",
No it is not.
The form of the command is makes this request:
Please look into that named <tree-ish>, and check out the named
<paths> out of it to my work tree. Because the reason I want them in
my work tree is so that I can include them as part of the next commit
I am preparing to create in the index, please update these paths in my
index while at it.
With that description, there's a bug: in addition to the above, it checks
out from the index any path which does match the <paths> but isn't in
<tree-ish>. I think the way to fix that would be to update the work tree
from read_tree_some() instead of using the "if pathspec_match() ...
checkout_entry()" loop over the index.
With the current code, you can have git check out a file that you've
changed/deleted from a tree that doesn't contain it at all (and you get
the index version). E.g.:
$ rm wt-status.c
$ git checkout e83c5163316f89bfbde7d9ab23ca2e25604af290 wt-status.c
$ ls wt-status.c
wt-status.c
(instead, you should get an error if a <path> doesn't match anything in
the <tree-ish> and only get those things that it matches in the
<tree-ish>.)
I think I was too zealous sharing code back in February. I should have a
patch by the weekend if nobody beats me to it. (And I still think that, if
you hit this case, you must be confused, but git isn't helping by doing
what it does.)
-Daniel
*This .sig left intentionally blank*
From: Boyd Stephen Smith Jr. <hidden> Date: 2016-06-15 22:45:51
On Tuesday 30 December 2008, Junio C Hamano [off-list ref] wrote
about 'Re: for newbs = little exercise / tutorial / warmup for windows and
other non-sophisticated new Git users :-) [Scanned]':
"Boyd Stephen Smith Jr." [off-list ref] writes:
quoted
"git checkout <branch> <paths>" is similar to "hg revert -r <branch>
<paths>",
No it is not.
The form of the command is makes this request:
Please look into that named <tree-ish>, and check out the named
<paths> out of it to my work tree.
That seems similar to "hg revert":
Using the -r option, revert the given files or directories to their
contents as of a specific revision.
Because the reason I want them in
my work tree is so that I can include them as part of the next commit
I am preparing to create in the index, please update these paths in
my index while at it.
This part is odd to me, but does make some sense. I can only think of a
few reasons to retrieve a file from a different tree-ish without
immediately turning around and doing "git add <bar>".
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/