Git status fatal not a git repository how to#
Git status fatal not a git repository update#

The worst kind of corruption in a git repository is corrupt or missing objects.Ĭorrupt objects are incredibly tricky to recover if you do not have a copy of git file inside the separate worktree and commondir should contain HEAD, index and logs/HEAD can be recovered as above. HEAD, index, logs/HEAD, gitdir and commondir. For each worktree, there is a separate directory containing at least Information about these worktrees is stored in the worktreesĭirectory. worktreesĪ feature still under heavy development is support for multiple worktrees for a Put your worktrees back if you had local changes, and you can commit those.

Git status fatal not a git repository update#

Have no changes) and simply run git submodule update to reclone them. The submodules' worktrees out of the way (or delete them if you're sure you If the modules directory is gone, git can get quite upset. If you still use this protocol and lost the info/ĭirectory of the repository that is being pulled from, you can recreate it with The info/ directory is mostly useless these days, as it is only used for the

Git status fatal not a git repository how to#

Objects, see below for tips and tricks on how to recover from this info If the directory is not gone completely, but you have some corrupt or missing Worktree, you can use it to start a new repository. Lives, and with it gone, what's left is useless. If the objects directory is gone, it's time to give up. Fortunately, these logsĪren't necessary for the normal operation of git and losing them only makes If the reflogs are gone, they cannot be recovered. Here's an example of recovering the master branch: Reflogs, you will find the correct value of a ref to on the last line of its

Values of refs : the reflog and the output of fsck. git/refs/heads to get git to recognize the repository atįor local refs, there are two locations where you can recover the previous When you lost all refs, you will first need to This will bring back refs in refs/remotes, and The simplest one is to fetch from a remote The refs directory contains all your branches, tags and other refs, except for In this case it is important though to recover things in the correct order. Goes to show that you can lose a lot of things and still keep git happy. We managed to recreate everything else, which was of course madeĮasier because he had only a single remote and a single branch. git/objects/ (seriously, how do people do Not even two weeks after the case of the missing files, a user popped into #git Local refs, see the recipe below that discusses losing the refs directory. TryĪ git fetch to see if some of them come back (tags and remote refs).

If the packed-refs file is gone, you might have lost an awful lot of refs. For head in $(git for-each-ref -format '%(refname:short)' refs/heads ) do if git rev-parse -q -verify origin/$head >/dev/null then