Ytukyg

Very strange, suddently, git show most of the files in my repo as removed. ls shows them, tree shows them, I can open them.

I try to copy the repository to another folder, git status shows the same...

Any idea how this can happen, and how to solve this ?

EDIT: I managed to solve temporary this by copying only the .git folder to another directory, git status this repo, and then copying again all files to the new folder. Then after a while, it reshows the files as deleted...

EDIT2: To solve this, while keeping a copy of all my files, I hard rest to head, and then recopy the backuped files to the repo. Now everything is fine.

EDIT3 (more infos):
I'm keeping a copy of the broken repo folder in case. I let the question open because I'm still wondering how this can happen!

>> cat $(find . -name .gitignore)

git

*.pyc

*.lprof

*.cprof

profile.sh

/doc/

/.idea/

__pycache__

/tmp/

(sorry, in french, I translated as I can). Lots of files, just showing some examples

 >> git status

 Sur la branche master (on the branch master)

...

Modifications qui seront validées : (modification that will be validated)

  (utilisez "git reset HEAD <fichier>..." pour désindexer)

    (supprimé = deleted)

    supprimé :        GUI/MainWindows.py

    supprimé :        GUI/PathParameters.py

    supprimé :        GUI/parameter_utils.py

    supprimé :        GUI/ui/ui_DefaultPathDialog.py

    supprimé :        GUI/ui/ui_mainGUI.py

    supprimé :        examples/__init__.py

    supprimé :        externals/__init__.py

    supprimé :        main.py

    supprimé :        tools/searchUtils.py

    supprimé :        tools/spatial.py

    supprimé :        tools/utils.py

    supprimé :        tools/yaml.py

    ....



Modifications qui ne seront pas validées : (modification that won't' be validated)

  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)

  (utilisez "git checkout -- <fichier>..." pour annuler les modifications dans la copie de travail)

    (modifié = modified)

    modifié :         GUI/ui/ui_mainGUI.ui

    modifié :         requirements.txt



Fichiers non suivis: (files not followed)

  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)



    GUI/MainWindows.py

    GUI/base/

    GUI/parameter_utils.py

    GUI/ui/ui_DefaultPathDialog.py

    GUI/ui/ui_mainGUI.py

    examples/

    externals/

    main.py

    tools/

git diff --cached shows a buch of the following, with the source code in red. It is very long, I wont put the source here. If you wan't more details, just ask !

>>git diff --cached



diff --git a/GUI/MainWindows.py b/GUI/MainWindows.py

deleted file mode 100644

index c9ef7ac..0000000

--- a/GUI/MainWindows.py

+++ /dev/null

as I explained, ls shows all the files listed as deleted above

Changes that are "to be committed" are those stored in the index (aka staging area aka cache). Git makes new commits from whatever is in the index right now, so a good description of the index is that it is what you are proposing to commit.

If you copied the repository, but did not copy the index (or copied it in some way that did not retain all of it), that would explain the problem. The index is neither the repository itself, nor the work-tree. Instead, the index sits between the repository and the work-tree. So the files can be there, in the work-tree, in fine order, but be missing from the index, and Git will tell you that a removal will be committed if you commit now.

You can tell Git to re-fill the index from the current commit, using git reset --mixed. Or, you can write specified (or all) work-tree files using git add. That is:

• 
  git reset --mixed: copy (all files) from HEAD to index


• 
  git add file: copy (the one specified file) from work-tree to index

If you view the index as being between the HEAD commit and the work-tree, this all makes more sense:

   HEAD           index         work-tree

----------      ----------      ----------

README.txt      README.txt      README.txt

file.ext        file.ext        file.ext

main.py         main.py         main.py

• The HEAD copy of each file is read-only: no commit can ever be changed, and it's a committed copy. These files are compressed—maybe highly compressed—and in a special, Git-only format.




• The index copy of each file is Git-only, like the HEAD copy, except that it's read/write: it has been unfrozen. The next commit will use the index copy, by freezing it (and once all the files are frozen and the commit is done, that index copy becomes the HEAD copy because HEAD changes to the new commit).




• The work-tree copy of each file is a normal file, in its normal form. Git doesn't use it to make commits. Git doesn't care very much about it, really; Git just provides it for you to use, work with, and maybe change if you like.

Once you've changed a file, you use git add to copy it back into the index, overwriting the old index copy. The add process compresses and Git-ifies the file, so that it's ready to be committed.

The git commit command takes whatever's in the index right now and freezes that into a new commit. The new commit becomes the HEAD commit.

When you first run git checkout branch, Git fills in the index and work-tree from the tip commit of branch. That commit becomes the HEAD commit, and the HEAD and index match. When you make a new commit, that new commit becomes the tip of the current branch, and the HEAD and index match. Note how the work-tree was merely an output of the initial checkout, not an input of the new commit. (It was, or rather some files in it were, put into to the index if you git add-ed some or all files.)

Normally you would remove files from the index using git rm:

• 
  git rm file removes file from both the index and the work-tree; or


• 
  git rm file removes file from the index, but leaves it alone in the work-tree.

Either way, after removing, say, file.ext from the index, you still have it in HEAD, so you have one of these two results:

   HEAD           index         work-tree

----------      ----------      ----------

README.txt      README.txt      README.txt

file.ext                        file.ext

main.py         main.py         main.py

or:

   HEAD           index         work-tree

----------      ----------      ----------

README.txt      README.txt      README.txt

file.ext

main.py         main.py         main.py

Looking in the work-tree won't tell you that the file's gone from the index, it will only tell you whether the file is gone from the work-tree. But git status will tell you, because git status runs two git diffs:

• First, git status compares the HEAD commit to the index. Whatever's different, Git tells you is a "change to be committed" ("qui seront validées", I guess). Whatever's the same, Git says nothing about.




• Then, git status compares the index to the work-tree. Whatever's different, Git tells you is a change that is not—at least, not yet—slated to be committed. You could git add the updated file into the index, of course; after that, the first comparison, HEAD vs index, will show something different.




• A file that is not in the index, but is in the work-tree, is said to be untracked ("non suivis"). This is true even if the file is in the HEAD commit. (Note, however, that you can suppress this complaint about untracked files by listing the file, or a pattern for it, in .gitignore.)

Conclusion: the files are in HEAD and the work-tree but not in the index

The output you showed is just what one should expect for this case. The file is in HEAD but not in the index: it will be missing from the next commit, unless you put it back into the index. And the file is not in the index, but is in the work-tree: it is untracked.