9

I was simply trying out a few things on a project and wanted to delete some modified files I was working with but no longer needed.

I got careless and typed git checkout file instead of git checkout -- file. So essentially I was just checking out this modified file and I have no clue where that modified file went off to.

I've tried using git update-index --fresh just to try and see where this modified file could have gone but it seems like it may have been deleted in the end? 

    modified:   test/ssc_test/cmod_tcsdirect_steam_test.cpp
    modified:   test/ssc_test/cmod_tcsfresnel_molten_salt_test.cpp
    modified:   test/ssc_test/cmod_tcsmolten_salt_test.cpp

These were the files I was trying to get rid of but forgot to add the -- to get rid of one of the edited files.

After checking out this file, instead of deleting it, it gave me the message, Updated 1 path from the index and it was no longer displayed along with the other modified files when using git status.

I'm pretty clueless with what happened exactly. Was it was deleted or hidden somewhere in the index, or something else?

StackzOfZtuff
  • 2,534
  • 1
  • 28
  • 25
finnahuss
  • 317
  • 3
  • 9
  • Did you have any another branches cloned ? – thar45 Aug 14 '19 at 18:08
  • 8
    `git checkout X`, for any X without the `--` in front, first tries to treat `X` as a *branch name*. If that works, you just did a checkout of that branch (and `git status` will tell you that you are `on branch X` now). If that *doesn't* work, Git tries to treat `X` as a commit hash ID: does `git rev-parse X^{commit}` succeed? If so, you did a checkout of that commit, and `git status` will say "detached HEAD". If not, the last resort is to act as if you ran `git checkout -- X`: try `X` as a file name. So you probably did the same as `git checkout -- file`. – torek Aug 14 '19 at 18:11
  • 1
    Note that `git status` won't *list* a file if it's in the index now and is *the same* as the copy in the `HEAD` commit *and* the same as the copy in the work-tree. That's when-and-why `git checkout -- X` makes file `X` drop out of the `git status` listing: Git replaced the work-tree `X` with the index version of `X`, and if the index version of `X` matches the `HEAD` version of `X`, all three copies now match. – torek Aug 14 '19 at 18:13
  • Why do you keep talking about “delete”? Checkout does not delete anything. – matt Aug 14 '19 at 20:03

3 Answers3

10

I got careless and typed 'git checkout file' instead of 'git checkout -- file'

Those commands do the same thing, unless for some reason teh actual name of file could be confused with a non-path argument to checkout.

Or to say that differently - the only thing -- does is to separate paths from other options in case it's ambiguous

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
3

In order to avoid any ambiguity between branch and file, you can use the new git restore command. See git restore.
It is available with Git 2.23, still experimental for now.

git restore -- afile

It will restore working tree files from any source you want.
By default, HEAD, but you can specify any treeish you want.

Using or not -- won't change anything.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
2

Git will set the file to the working head/index.

To test and illustrate:

mkdir test
cd test
git init
touch testfile
git add --all
git commit -m "Commit"
echo hi > testfile
cat testfile # hi
git checkout testfile
# Testfile is now empty
Julie Nielsen
  • 91
  • 7