"Boyd Stephen Smith Jr." <bss@xxxxxxxxxxxxxxxxx> writes:
> On Tuesday 2008 December 30 20:30:46 Conor Rafferty wrote:
>> MERCURIAL:
>>
>> Update
>> hg update [-C] [-d DATE] [[-r] REV]
>
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
