Re: git fsck: unreachable vs. dangling

Sebastian Schuberth [off-list ref] writes:

On Tue, Apr 14, 2015 at 10:50 AM, Michael J Gruber
[off-list ref] wrote:

quoted

"to dangle" means "to hang loosely".

So, in the description above, "A^ dangles from A loosely" because it
hangs from A (you can reach it from A) but loosely, because it would
"drop" if A gets dropped and A is "likely" to be dropped (because it is
unreachable by refs). But A^ is not dangling in our terminology.

If you *reverse the arrows*, i.e. consider A^ pointing to A, it becomes
more apparent that A is dangling: it is an unreferenced leaf node.

That's exactly what confused me. In the very literal sense, something
can only "hang loosely", i.e. dangle, if it's only tied at *one* end,
and that's the case for A (which is only connected to A^) but not for
A^ (which is connected to its parent, and A). Especially when talking
about A as a "leaf" node, like in the leaf of a natural tree, I would
think that A is dangling.

I am not sure if I follow, but probably it is just me who is not
strong at math, or whose eyesight is not keen enough to notice the
arrow heads on links between the commits.

I just visualize commits to be ping-pong balls with strings between
them, and then grab the root of the graph and lift the whole thing
up, while tips of the branches and tags are anchored.  Commit A will
be dangling in the wind if you shake the whole thing.

But that visualization breaks down once you start thinking about
what will happen to A^{tree} and its blobs; they are attached to A
with thin strings and they will have to float above A (i.e. sit
somewhere closer to the root of the tree) just like A^ will go
closer to the root, to make A appear the "dangling" one, as the
direction of the arrow is from A to A^{tree} just like we have an
arrow from A to A^; just like A^ is not dangling because of A,
A^{tree} is not dangling.