To address the broken link from tree to tree error in Git, you need to identify the missing objects and attempt to recover them or remove references to them.
Git Repository Structure
├─📂 .git/
│ ├─📁 objects/
│ │ ├─💔 broken link from tree 4bf48692... to tree df084ac4...
│ │ └─💔 broken link from tree 4bf48692... to tree d193ccbc...
│ └─📁 refs/
└─📄 other repository files
With Git 2.10 (Q3 2016), you can know more about the origin of those broken links.
git fsck --name-objects
See commit 90cf590, commit 1cd772c, commit 7b35efd, commit 993a21b (17 Jul 2016) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 9db3979, 25 Jul 2016)
fsck: optionally show more helpful info for broken links
When reporting broken links between commits/trees/blobs, it would be quite helpful at times if the user would be told how the object is supposed to be reachable.
With the new --name-objects option, git-fsck will try to do exactly that:
name the objects in a way that shows how they are reachable.
For example, when some reflog got corrupted and a blob is missing that should not be, the user might want to remove the corresponding reflog entry.
This option helps them find that entry: git fsck --name-objects will now report something like this:
broken link from tree b5eb6ff... (refs/stash@{<date>}~37:)
to blob ec5cf80...
If those broken links don't come from a local stash but a remote repo, fetching those pack objects can then solve the situation.
See also "How to recover Git objects damaged by hard disk failure?".
With Git 2.31 (Q1 2021), fix "git fsck --name-objects"(man) which apparently has not been used by anybody who is motivated enough to report breakage.
See commit e89f893, commit 8c891ee (10 Feb 2021) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 9e634a9, 17 Feb 2021)
fsck --name-objects: be more careful parsing generation numbers
Signed-off-by: Johannes Schindelin
In 7b35efd (fsck_walk(): optionally name objects on the go, 2016-07-17, Git v2.10.0-rc0 -- merge listed in batch #7) (fsck_walk(): optionally name objects on the go, 2016-07-17), the fsck machinery learned to optionally name the objects, so that it is easier to see what part of the repository is in a bad shape, say, when objects are missing.
To save on complexity, this machinery uses a parser to determine the name of a parent given a commit's name: any ~<n> suffix is parsed and the parent's name is formed from the prefix together with ~<n+1>.
However, this parser has a bug: if it finds a suffix <n> that is not ~<n>, it will mistake the empty string for the prefix and <n> for the generation number.
In other words, it will generate a name of the form ~<bogus-number>.
Let's fix this.
With Git 2.40 (Q1 2023), "git hash-object"(man) now checks that the resulting object is well formed with the same code as git fsck".
See commit 8e43090 (19 Jan 2023), and commit 69bbbe4, commit 35ff327, commit 34959d8, commit ad5dfea, commit 61cc4be, commit 6e26460 (18 Jan 2023) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit abf2bb8, 30 Jan 2023)
hash-object: use fsck for object checks
Signed-off-by: Jeff King
Since c879daa ("Make hash-object more robust against malformed objects", 2011-02-05, Git v1.7.5-rc0 -- merge), we've done some rudimentary checks against objects we're about to write by running them through our usual parsers for trees, commits, and tags.
These parsers catch some problems, but they are not nearly as careful as the fsck functions (which make sense; the parsers are designed to be fast and forgiving, bailing only when the input is unintelligible).
We are better off doing the more thorough fsck checks when writing objects.
Doing so at write time is much better than writing garbage only to find out later (after building more history atop it!) that fsck complains about it, or hosts with transfer.fsckObjects reject it.
This is obviously going to be a user-visible behavior change, and the test changes earlier in this series show the scope of the impact.
But I'd argue that this is OK:
- the documentation for
hash-object is already vague about which checks we might do, saying that --literally will allow any garbage[...] which might not otherwise pass standard object parsing or git-fsck(man) checks".
So we are already covered under the documented behavior.
- users don't generally run hash-object anyway.
There are a lot of spots in the tests that needed to be updated because creating garbage objects is something that Git's tests disproportionately do.
- it's hard to imagine anyone thinking the new behavior is worse.
Any object we reject would be a potential problem down the road for the user.
And if they really want to create garbage, --literally is already the escape hatch they need.
Note that the change here is actually in index_mem(), which handles the HASH_FORMAT_CHECK flag passed by hash-object.
That flag is also used by "git-replace --edit"(man) to sanity-check the result.
Covering that with more thorough checks likewise seems like a good thing.
Besides being more thorough, there are a few other bonuses:
we get rid of some questionable stack allocations of object structs.
These don't seem to currently cause any problems in practice, but they subtly violate some of the assumptions made by the rest of the code (e.g., the "struct commit" we put on the stack and zero-initialize will not have a proper index from alloc_comit_index().
likewise, those parsed object structs are the source of some small memory leaks
the resulting messages are much better.
For example:
[before]
$ echo 'tree 123' | git hash-object -t commit --stdin
error: bogus commit object 0000000000000000000000000000000000000000
fatal: corrupt commit
[after]
$ echo 'tree 123' | git.compile hash-object -t commit --stdin
error: object fails fsck: badTreeSha1: invalid 'tree' line format - bad sha1
fatal: refusing to create malformed object
After identifying the broken links with git fsck --name-objects, you can proceed with the repair process:
Restore Missing Objects: If you have access to a backup or a remote copy of the repository that is free from these errors, you can try to restore the missing or corrupted objects by fetching them:
git fetch origin
Clone a New Repository: Sometimes, cloning a fresh copy of the repository is the simplest way to resolve corruption issues:
git clone <repository-url>
Try and recover from that other repository.
Manual Cleanup: After trying restoration or re-cloning, run git fsck --full again to verify the repository's integrity. Address any identified issues as suggested by the output.
Remove any dangling object.
Use Advanced Repair Tools: In more severe cases, where standard recovery methods fail, consider using advanced tools like git-repair. That tool attempts to fix the repository by applying more aggressive repair strategies:
git-repair
(Installation may be required.)
git-repair starts by deleting all corrupt objects, and retrieving all missing objects that it can from the remotes of the repository.
If that is not sufficient to fully recover the repository, it can also reset branches back to commits before the corruption happened, delete branches that are no longer available due to the lost data, and remove any missing files from the index. It will only do this if run with the --force option, since that rewrites history and throws out missing data.
git fsck --name-objectscan help. See my answer below – Bogochmain, and I couldn't cleanly pull my localmainto it. I found this article: blog.pterodactylus.net/2020/10/18/… which helped me recover the missing/corrupt packs, fixing the broken links. – Beekman