CODEWITHSUNDEEP
git
1252748
1252748

Reputation: 15372

Should git checkout bypass index and only update working tree?

From the Atlassian docs:

Git Checkout File

Checking out a file is similar to using git reset with a file path, except it updates the working directory* instead of the stage. Unlike the commit-level version of this command, this does not move the HEAD reference, which means that you won’t switch branches.

And a bit farther down:

If you stage** and commit the checked-out file, this has the effect of “reverting” to the old version of that file.

However when I git checkout <sha1> -- <file> I see the change added to both my working tree (ie, the file in sublime updates) and git status shows the modification to the file is green and in staged/in-index. (Verified by git diff giving empty output.)

Is my git misconfigured, are their docs incorrect, or have I misunderstood them?

*their emphasis

**my emphasis

Upvotes: 0

Views: 139

Answers (1)

torek
torek

Reputation: 488183

The Atlassian document is completely wrong here.

git checkout tree-ish -- path copies the specified path first to your index (aka staging-area), then from your index to your work-tree. This overwrites whatever was in the index before. The tree-ish here is how the Git documentation means to tell you that anything that will find a commit or a commit's tree object suffices. Mostly people use commit hash IDs, branch names, and relative names like HEAD~3 here, but anything from the gitrevisions documentation suffices.

(To check out a commit, the checkout code needs a commit hash, in which case only a commit ID will do. For this particular case, though, it only needs to find the source tree snapshot associated with the commit ID. Git can use the commit to find the tree just like it does for a commit checkout, but you can supply the tree hash ID itself directly. There's almost never a reason for a human to do this, but some software might want to. See also the git rev-parse documentation.)

Note, however, that git checkout -- path copies from your index to your work-tree (without first extracting from tree-ish to index). This can lead to the wrong assumption that they made.

There is a way to extract a file directly from a commit to your work-tree, without first going through your index, using git show or git cat-file -p. In older versions of Git this process always skips any end-of-line and other filter and text-conversion items, which git checkout does for you normally; in newer Gits, you can force these conversions to occur the way they would with git checkout. This caveat only matters if you are using smudge filters, the ident filter, or CRLF line-ending conversion options.

Upvotes: 2

Related Questions