git status shows untouched files as modified, and git diff cannot hash them

Viewed 411

Ubuntu 16.04, git version 2.7.4

I have been developing some code locally that is also hosted remotely. Today, and a few other times earlier occasionally, what follows happens. The other times it disappeared after just waiting sceptically, but now it seems to be persistent.

Step 1, pass: synchronize current branch with remote

git pull
Already up-to-date.

Step 2, fail: check status and new modified files show up out of the blue

git status

On branch [mybranch]
Your branch is up-to-date with 'origin/[mybranch]'.
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)

some 30+ files are given as modified, even though I don't quite think they have been changed

(After reboot they have become 15, erratically. After another reboot, 3. Take note: no action on the files)

Step 3: inquiry what the difference would be

Probing the situation with a couple of files, I get

git diff ../../[directory]/[directory]/[file].md5
error: short read No such file or directory
error: [directory]/[directory]/[file].md5: failed to insert into database
fatal: cannot hash [directory]/[directory]/[file].md5

Research

Thinking of Git shows all files as modified after changing file permission, I don't think to have changed permissions any recently. Those files are quite fossilised.

Questions

What is the possible cause of this situation, and how to prevent that this happens again?

And why would it self-heal automagically at times, and persist at others?

1 Answers

Ubuntu 16.04, git version 2.7.4, Doxygen 1.8.12

Diagnose

The offending files were elements of a Doxygen documentation and were stored in a single directory of 507M and 19,415 files. Probably this confused the book-keeping in git, my first assumption.

Cure

Doxygen has an option in the configuration file to distribute files over different directories, actually with a tree structure similar way to how git does

# If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-
# directories (in 2 levels) under the output directory of each output format and
# will distribute the generated files over these directories. Enabling this
# option can be useful when feeding doxygen a huge amount of source files, where
# putting all generated files in the same directory would otherwise causes
# performance problems for the file system.
# The default value is: NO.

CREATE_SUBDIRS = YES

I have set this to yes, and cycled over

git status; git add .; git commit -m ...; git push

a couple of times until I got:

git status
On branch [mybranch]
Your branch is up-to-date with 'origin/[mybranch]'.
nothing to commit, working directory clean

which sorts out the problem in Step 2 above.

Trivia

For the curious reader I found these other posts which kind of corroborated my approach, at least give me some clues that it was worth trying:

Any expert/experienced that wish to raise the quality of this answer, be my guest.

Related