Clemens Buchacher <drizzd@xxxxxx> writes: > Every reference to git fsck that I could find in the documentation or on > the web is followed by the some kind of assurance that dangling objects > are "not a problem", "nothing to worry about" or "not at all > interesting". > > Instead of telling the user everywhere to ignore those messages, let's > not print them in the first place. The --dangling flag can be used to > explicitly enable printing dangling objects. > > Signed-off-by: Clemens Buchacher <drizzd@xxxxxx> Thanks. I think that both the ultimate goal explained above, and the direction in which the documentation updates tries to move us, are good. I only gave a cursory look at the code changes, but what they implement seems to match the intention. Of course I may be missing something, so objections from others to argue why we shouldn't do this is very much welcomed to stop me and Clemens ;-). > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt > index f13a846..09ffbcc 100644 > --- a/Documentation/user-manual.txt > +++ b/Documentation/user-manual.txt > @@ -1582,25 +1582,12 @@ Checking the repository for corruption > > The linkgit:git-fsck[1] command runs a number of self-consistency checks > on the repository, and reports on any problems. This may take some > +time. > ... > -Dangling objects are not a problem. At worst they may take up a little > -extra disk space. They can sometimes provide a last-resort method for > -recovering lost work--see <<dangling-objects>> for details. Losing this description is not a problem and is indeed an improvement in this section in the user manual, but let's make a mental note that the user needs to also learn what the third sentence says elsewhere in this document. << reads on >> > @@ -1665,7 +1652,7 @@ commits in the dangling objects that `git fsck` reports. See > <<dangling-objects>> for the details. > > ------------------------------------------------- > -$ git fsck > +$ git fsck --dangling > dangling commit 7281251ddd2a61e38657c827739c57015671a6b3 > dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63 > dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5 > @@ -3301,9 +3288,6 @@ broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 > missing blob 4b9458b3786228369c63936db65827de3cc06200 > ------------------------------------------------ > > -(Typically there will be some "dangling object" messages too, but they > -aren't interesting.) > - The old sentence becomes stale as the example _explicitly_ asks the command to show the dangling ones. > Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6 > points to it. If you could find just one copy of that missing blob > object, possibly in some other repository, you could move it into And this part, together with the introductory text of the section (not shown in the context), says what the "third sentence" above wanted to say. So overall I think this is a vast improvement without losing any information or clarity. Nice. -- 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