From: Linus Torvalds Date: Sun, 18 Sep 2005 21:43:33 GMT Subject: Re: git fsck messages - what to do about it? Message-ID: In-Reply-To: On Fri, 16 Sep 2005, Linus Torvalds wrote: > > > b) Is there any way to find out what I did wrong in the first place? > > Well, it probably isn't even an error, but there are nice tools to check > it out. For example, you can just list the commits it lists to gitk, and > you'll get a nice graphical view of where they are in the tree. That > probably makes you go "Duh, yes, I did a 'git reset' to undo those". Oh, btw, one final note on this problem. The "--unreachable" flag is meant to show a list of all objects that aren't reachable from the refs (either the explicit ones, or the ones git-fsck-objects finds on its own). That's very useful for when you actually want to remove them, ie "git prune" uses that flag. However, it's often not very interesting to see the full list of unreachable objects, because you are probably _not_ interested in the trees that are reachable from the unreachable commit - you're really interested in the "tips of unreachability". And that's what git-fsck-object actually reports _without_ any flags, as "dangling" objects. So let's say that you have one commit that you've undone. If you don't give any flags at all, git-fsck-objects will report dangling commit ... but if you use "--unreachable" then you'll get the full list of objects, so you'll get unreachable tree ... unreachable blob ... unreachable commit ... unreachable blob ... which is usually _not_ what you want. Similarly, let's say that you undid a series of three commits. There is only one "dangling" commit (the "tip" of the series), but there are three unreachable commits (and any number of unreachable trees/blobs associated with those commits). Again, what a human tends to be interested in is the "dangling tip", not the whole collection of unreachable objects that can be reached through that tip. So using "--unreachable" gives much more raw data, but it usually tends to hide the real _information_, and the end result is thus much harder to understand. Linus