简体   繁体   中英

error: pathspec '…' did not match any file(s) known to git

I'm calling git checkout HEAD~2 "Finished 1 stage" (or just git checkout "Finished 1 stage" )

Then i get error: pathspec 'Finished 1 stage' did not match any file(s) known to git

git log: git log

I'm trying to get files from commit "Finished 1 stage"

I hope you will help me!

When you say

git checkout HEAD~2 

then you checkout to the commit which is 2 commits behind HEAD which is the head of the branch. You probably just need the command above.

Your error message suggests that "Finished 1 stage" is a not existing file. Apparently that's a commit message, that's unnecessarily passed and git interprets

git checkout HEAD~2 "Finished 1 stage"

as

checkout to HEAD~2, but only for the file called "Finished 1 stage"

I'm trying to get files from commit "Finished 1 stage"

In Git, commits are numbered , as a big long ugly hexadecimal number. What git checkout or git restore actually needs here is the commit's number . So at the raw level you might write:

git checkout a123456

This means switch to that (entire) commit (as a "detached HEAD"); your working tree will then consist of files from that commit, plus any untracked files that Git does not touch, that remain in place from before. 1

If you only want some particular files from that particular commit, the best—as in safest—way to express that is:

git checkout a123456 -- path/to/file1.ext name/of/file2.ext

for instance. Note that this request means destroy any unsaved work I have in these two files and Git will do that without asking. The two dashes here, -- , separate the commit specifier a123456 from the two path names. If you omit the two dashes, Git assumes them, as long as the file names do not resemble option specifiers or similar . For instance, suppose you want to get a file named -b . The name -b also looks like the option -b . The two dashes help Git be sure that something is an option (if it's on the left side of the -- ) or isn't an option (if it's on the right side of the -- ).

Now, those big ugly hash IDs are hard to type. You can use git log to find the commit you want, then use the mouse to cut-and-paste the hash ID. But that's still not very pretty. Sometimes it might be nice to use something other than a big ugly hash ID, or even an abbreviated one like a123456 . Your use of HEAD~2 is a way to avoid having to type in the hash ID.

If HEAD~2 names that commit—which it might—then HEAD~2 is all you need and is all you should enter . The commit's subject text, such as "Finished 1 stage", should not be included here.

To see the hash ID from HEAD~2 , you can run git rev-parse . This command isn't all that interesting except in terms of illustrating how git checkout turns the string HEAD~2 into a hash ID:

$ git rev-parse HEAD~2
7652ce966f9b398e02a5df0344d015c4d54ca52a

(your results will differ). To get a better look at the commit, consider using git show :

$ git show HEAD~2

(output not included here).

There are ways to use the log messages to search for a commit. These are described in the gitrevisions documentation , which is worth repeated reading over time. But if HEAD~2 suffices, you should probably just use that.


1 There is a special case for files that you have modified but not yet committed. For the gory details, see Checkout another branch when there are uncommitted changes on the current branch .

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM