CODEWITHSUNDEEP
gitgithubrepositorydiagnostics
lo tolmencre
lo tolmencre

Reputation: 3954

How to diagnose a broken git repository

I have a reoccurring issue of my repository breaking. Several times a day in fact. This seems to happen when I kill the kernel in a jupyter notebook that I have in it. Another thing I suspect being at fault here is LFS which is an extension for large files for git.

In the broken state most git commands such as add and status stop working inside the repo. When the commands are executed the terminal just stalls. Another thing that happens is that zsh (using git extension) breaks as well once I cd into the repo. The shell stalls and cannot be recovered.

I would like to know a way to diagnose the repo when it is in this state to find out what the cause of this repeated breaking is.

I don't exactly require help to recover the repo, as I have a backup and can set it up again easily. But doing this 4 times a day gets kind of annoying...

Upvotes: 0

Views: 728

Answers (1)

torek
torek

Reputation: 489688

I suspect the same thing that you do: that Git-LFS is involved.

When using Git-LFS, many operations within a repository, including adding files with git add, must proceed with the assistance of filters, which Git calls smuge and clean filters. Running git status does not always need any of the filters, so that's a clue that there may be something else involved (instead or as well), but the filters are an obvious place for things to go wrong. Your shell probably has some shell magic to fiddle with the prompt ($PS1) in a Git repository, so it is running Git commands that hang, waiting for the filter(s) to complete.

If this is the case, disabling the filters will demonstrate it as things will start working again. To disable the filters, carefully move any .gitattributes and/or .git/info/attributes file(s) out of the way.1 Then cd into the repo and see if things are working. If so, it's not just Git-LFS, it is specifically the filters.

The LFS filters work by inspecting and changing the contents of each as-stored-in-Git file—i.e., the blob objects in the repository database, stored via commits and their trees and listed in your Git's index file—vs the contents of files stored in the work-tree. A small file is left alone. For a large file, however, LFS tells Git: Pay no attention to that file! Let me give you a URL (and maybe a bit of auxiliary data) instead! LFS copies the file over the network from or to the large file storage annex, wherever that is, while Git only ever sees / stores the URL.

If the filter process itself hangs, or if the large-file-storage-annex is unreachable, Git will just sit there waiting, potentially forever. If you can still work with another clone of the repository, it must be the case that the LFS-annex is reachable and therefore it must be the filter process itself that become stuck.

You can look at all processes running on your system and find the stuck filter(s) and terminate it / them. That may or may not make the repository work again, depending on precisely why and how they got stuck.

1There could be more than one. I have not played with Git-LFS. My understanding is that it uses just one, but that might be wrong. Note that the filters themselves are defined in .git/config, but are used because of entries in .gitattributes or $GIT_DIR/info/attributes.

Upvotes: 1

Related Questions