From: "Shawn O. Pearce" <spearce@spearce.org>
To: Larry Streepy <larry@lightspeed.com>
Cc: git@vger.kernel.org
Subject: Re: Question about fsck-objects output
Date: Thu, 25 Jan 2007 14:31:12 -0500 [thread overview]
Message-ID: <20070125193112.GE13089@spearce.org> (raw)
In-Reply-To: <45B8F575.5050106@lightspeed.com>
Larry Streepy <larry@lightspeed.com> 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.
next prev parent reply other threads:[~2007-01-25 19:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-25 18:22 Question about fsck-objects output Larry Streepy
2007-01-25 19:31 ` Shawn O. Pearce [this message]
2007-01-25 20:01 ` Linus Torvalds
2007-01-25 20:08 ` Larry Streepy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070125193112.GE13089@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=larry@lightspeed.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).