Git: Are these chatter?

Question

At the end, the extracted screenshot from the source tree of the SourceTree branches is shown (there is a gap in the middle of the screenshot)

In this case, #1 points to the line that was used for branching on 1.7.6.14.X and #2 , indicates the current status of the same branch.

The end referenced by #3 , and the previous 8 commits to this line, were previously attached to the 1.7.6.14.X branch. Then another developer allegedly checked one branch and made the fix pointed to by #4 . This #4 commit removed the former 9 commits from the 1.7.6.14.X branch and left them hanging out.
As a result, the branch 1.7.6.14.X now starts from the starting branch point, and not just from commit #3 .

Running git fsck with --unreachable , --dangling etc. does not give any errors. I tried --lost-found .

However, git fsck <hash of commit #3> creates five dangling commits and a whole chain of hanging tags:

 Checking object directories: 100% (256/256), done. Checking objects: 100% (3148/3148), done. dangling commit ec213... dangling commit ab82a... dangling commit 7d262... dangling commit a6f06... dangling commit 6674a... 

I have two questions:

• What could lead to this situation (i.e. branch #1 disconnecting)?

• How to determine if there are similar problems in other repositories? ( without to know the hashes of individual commands such as #3 )

Update

We found the answer to question (1). The situation was caused by a forceful push of a central bare repo by a developer who had an old snapshot of a branch.

Answer 1

• as you said; this is caused by using git push --force
• Since all your commits are reachable with a tag; git will never say that they are hanging since they are not . They will never be lost or cleared, as the tag refers to them.

As for how to find them (due to the lack of a better word), deceives; I did not find git, but came up with a small script that allows them to be detected. There may be a way to make this more efficient, but it does the trick:

 for sha in $(git log --all --pretty=format:"%H") do if [ -z "$(git branch --contains $sha)" ] then echo "commit not on a branch: $sha" fi done 

note I know that the test -z "" not very clean, but the return value of git branch always 0 ...

Answer 2

Here is the Linus Torvalds post:

Linus describes what ragged objects are when they are left, and how to view their relationship with branches in gitk

---

What could lead to the situation (that is, department # 1 is separated)?

Hanging data is data that is stored in the git repository but not available.
This means that you have (added or perfect) content that is not available in your repository (without committing or branching or pointing to this content)

So, yes, all commits on branch # 1 are not available from any commits next to branch # 1.

---

How to determine if there are similar problems in other repositories? (not knowing the hashes of individual commits like # 3)

 git fsck --full 

This command will check all dangling content in your repository.

---

Your repository can have 2 types of dangling content:

Hanging blob

Changes made to the staging area / index (after you do git add git calculated by SHA-1 and start tracking content), but never got it.

Dangling commit

Commit (s), which are not associated with any branch or tag, either directly or by any of its descendants.