Re: Question about fsck-objects output

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Larry Streepy <larry@xxxxxxxxxxxxxx> wrote:
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]