What does the command `git checkout . path/to/file.php` do?

Question

I have several modified files, my git status looks like

$ git status
On branch loyalty-module
Your branch is up-to-date with 'origin/loyalty-module'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   this/is/a/path/to/AFile.php
    modified:   this/is/another/file/A.php
    modified:   this/is/another/file/B.php

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    system/logs/test.log
    system/logs/test-api.log

no changes added to commit (use "git add" and/or "git commit -a")

Accidentally, I run this command git checkout . this/is/a/path/to/AFile.php. Notice the period!

When, I run the git status again, all I've got is the Untracked files.

$ git status
On branch loyalty-module
Your branch is up-to-date with 'origin/loyalty-module'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    system/logs/test.log
    system/logs/test-api.log

no changes added to commit (use "git add" and/or "git commit -a")

What does git checkout . do? And how can I retrieve those modified files again?

Does this answer your question? [Git checkout with dot](https://stackoverflow.com/questions/14460595/git-checkout-with-dot) — mnestorov, Sep 15 '21 at 10:26
@mnestorov No. The 2 from 3 of modified files are still there modified, but when I run `git status`, it only shows the untracked files. I mention in the question that I run `git checkout . this/is/a/path/to/AFile.php`, dot with a modified file. When I try to add n commit, there's nothing change. — Morilla Thaisa, Sep 15 '21 at 13:41

score 0 · Accepted Answer · answered Sep 15 '21 at 10:28

A dot by itself like this is generally a pathspec in Git. It means the current directory, which usually—because Git mostly doesn't believe in folders/directories¹—means all files in the current directory and all subdirectories thereof. So:

git checkout .

is an instruction to Git: please destroy all the hard work I just did.²

And how can I retrieve those modified files again?

You can't, in Git anyway. Your editor, or macOS Time Machine, or some other outside-Git method may provide a way to get them back.

One lesson to take away here is that git checkout has two modes:

git checkout branch-name operates in a "safe mode", where it first checks to see if it will destroy hours (or minutes, or days, or whatever) of work. If so, it says: no, that would destroy your hard work and you get a chance to save it first.
git checkout path-spec operates in the "unsafe mode", immediately wiping out any work you did in any specified path.

Sometimes, as with ., it is clear that this path spec cannot be a branch name (. is not a legal branch name), but sometimes it's not clear at all: git checkout dev—is dev a directory with lots of files, or is it a branch name? So you might want to use the newfangled git switch and git restore commands, available since Git version 2.23:

git switch takes branch names and operates in safe mode.
git restore takes pathspecs and operates in unsafe mode.

There's never any question as to whether git _____ dev is safe or unsafe because the blank you fill in–with switch or restore—tells you.

¹This is a slight overstatement: Git of course knows all about folders; it has to, as your OS requires this. But Git doesn't use them inside the files stored inside commits: files in commits just have long names with embedded forward slashes. The name path/to/file is not a directory path containing a directory to containing a file file, it's just a file literally named path/to/file.

Technically, this is what shows up in Git's index, also known as the staging area, but since everything has to pass through Git's index / staging-area, that's why Git doesn't store directories, and you can't make it save an empty folder. See also How can I add a blank directory to a Git repository?

²Technically, it's a request to copy files from the index into your working tree. Since you had not staged those files for commit, though, this was the effect.

The things is the 2 files of modified files from the 3 is actually modified, but when I `git commit` there's nothing to be committed. — Morilla Thaisa, Sep 15 '21 at 10:51
I don't know what you mean by "actually modified": your `git checkout` command *threw out* your changes, so they're *not* modified now. If you have backups in your editor or outside Git, you can use those to get your changes back. Otherwise, they are *gone*. — torek, Sep 16 '21 at 00:41
"actually modified" = my edit is still there but git cannot detect it's modified — Morilla Thaisa, Sep 16 '21 at 07:34
You mean that if you open the file in your editor, you see the file contents you want? If so, instruct your editor to write that file out (over top of the existing file, or somewhere else) because your editor still has the right contents, even though Git has overwritten the file with the *old* contents. That's how you'll save the desired data. — torek, Sep 16 '21 at 07:43
Once the file has been re-updated with the desired contents, Git should see it as changed. — torek, Sep 16 '21 at 07:44
My bad. You are right, @torek. I've seen them "modified" from a browser, which is cached. But when I check the files, it restored. Thanks. — Morilla Thaisa, Oct 02 '21 at 12:27

What does the command `git checkout . path/to/file.php` do?

1 Answers1