19
My repository has momentarily corrupted after the yesterday’s blackout in Brazil. I managed to heal the corruption (thus) and decided to run a git fsck to check the status of my local repository. Here it responds by saying that there are dangling commits:
On another occasion he also told me that there were dangling Objects, but I didn’t keep the print.
What is a dangling commit? Does it have anything to do with dangling Object?
Like these things dangling arise?
8
The dangling Objects are data that are stored in the repository but cannot be accessed by normal means, as no branch or tag points to them.
It’s natural for these objects to exist in your repository over time, as they’re a means for Git to ensure that you don’t lose some information even if you make a mistake or regret an action.
There are two types of data dangling: blob and commit.
The dangling commits are commits that belonged to some branch or tag, but this branch/tag has been removed from the repository. Git keeps these commits inside the repository, but they’re not naturally reachable.
The dangling blobs are data that are in the index (staging area) but the user never committed them. They also have a hash because when you make a git add git already calculates the SHA-1 of the content.
However, these objects don’t stay in the repository forever. Git runs, from time to time, a git gc to make a cleaning up and optimization in the repository, removing objects that are in this state and that are older than 2 weeks.
5
Basically, as it hears the blackout in which you spoke and you managed to restore the files, the dangling commits or dangling Objects, is the term in which the log is shown as a Tree or object that has been corrupted and has been restored successfully. So the log appears dangling commits or dangling Objects.
Browser other questions tagged git terminology
You are not signed in. Login or sign up in order to post.
I don’t know how much is "emergency" or if the question is merely educational (probably ;) ), but here’s what’s essential for data recovery if you need https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery - Too bad I can’t stop to answer officially now.
– Bacco
@Bacco, is educational. Sometimes running the
pruneand thegc --aggressivethese objects died. I was curious to know what they were.– Jefferson Quesado
As a matter of fact, it’s something that got "orphaned" or left over from some previous operation. You can kill the remains, but it is a chance of data recovery in case of abnormal situations. It could well have happened that you committed something that was not completed, and for some reason needed to recover the data that was sent and stayed in this "parallel universe". (again, it’s a very precarious explanation)
– Bacco
@Bacchus, when available to turn the commentary into a canonical response, thank you. I imagine a poorly done/constantly interrupting fetch may cause this problem as well, along with the problematic commit (close the machine and force hibernation at fetch time is common for me, forgive me... commits are usually more guaranteed to operate to reasonably safe and verified order).
– Jefferson Quesado
If someone more specialized in GIT terminology does it, I think it comes out better than I do. I just wanted to kick off. If you do not have the availability to post and no one does, who knows I will arrange a little time to study the subject better (great chance that I end up not doing) :)
– Bacco