Re: Question about fsck-objects output

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jan 25, 2007, 19:31 UTC
Message-ID: <20070125193112.GE13089@spearce.org>
In-Reply-To: <45B8F575.5050106@lightspeed.com>

Larry Streepy <larry@lightspeed.com> wrote:

Show 19 quoted lines

> Sorry to ask such a basic question, but I can't quite decipher the output 
> of fsck-objects.  When I run it, I get this:
> 
>  git fsck-objects
> dangling commit 2213f6d4dd39ca8baebd0427723723e63208521b
> dangling commit f0d4e00196bd5ee54463e9ea7a0f0e8303da767f
> dangling blob 6a6d0b01b3e96d49a8f2c7addd4ef8c3bd1f5761
> 
> 
> Even after a "repack -a -d" they still exist.  The man page has a short 
> explanation, but, at least for me, it wasn't fully enlightening. :-)
> 
> The man page says that dangling commits could be "root" commits, but since 
> my repo started as a clone of another repo, I don't see how I could have 
> any root commits.  Also, the page doesn't really describe what a dangling 
> blob is.
> 
> So, can someone explain what these artifacts are and if they are a problem 
> that I should be worried about?

These were probably created by amending a commit (`git commit --amend`).

Dangling commits simply mean no existing branch points at them, either directly by a ref/tag or indirectly by the commit being merged into them. They aren't part of any interesting history. They could also be caused by deleting a branch before it was fully merged into another branch. The commits and history are still there, they just lack a name.

Dangling blobs mean the same thing; no existing branch uses them in their revisions.

What most likely happened here was you committed a change, realized it was slightly wrong, modified one file, then used `git commit --amend -a` to update the commit with the correction. Later you probably did the same thing, but only to correct the commit message. The first instance caused the blob and commit to dangle, the second caused another commit to dangle.

You can use `git show id` (where id is the commit id above) to see what the commit actually is.

You can use `git prune` to have these objects deleted. For safety reasons `repack -a -d` won't touch them. But they don't take up a lot of disk space (usually) so pruning isn't something to be too concerned about.

-- 
Shawn.