{"thread":{"id":"29748","subject":"[PATCH] fsck: do not print dangling objects by default","startedAt":"2012-02-26T20:43:57Z","lastAt":"2012-02-28T23:25:20Z","messageCount":11,"participants":["Clemens Buchacher","Junio C Hamano","Zbigniew Jędrzejewski-Szmek","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"185468","messageId":"20120226204357.GA26088@ecki","threadId":"29748","inReplyTo":null,"subject":"[PATCH] fsck: do not print dangling objects by default","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-02-26T20:43:57Z","receivedAt":"2012-02-26T20:43:57Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"Every reference to git fsck that I could find in the documentation or on\nthe web is followed by the some kind of assurance that dangling objects\nare \"not a problem\", \"nothing to worry about\" or \"not at all\ninteresting\".\n\nInstead of telling the user everywhere to ignore those messages, let's\nnot print them in the first place. The --dangling flag can be used to\nexplicitly enable printing dangling objects.\n\nSigned-off-by: Clemens Buchacher <drizzd@aon.at>\n---\n Documentation/git-fsck.txt    |    3 +++\n Documentation/git-repack.txt  |    2 +-\n Documentation/user-manual.txt |   20 ++------------------\n builtin/fsck.c                |    7 +++++--\n t/t1410-reflog.sh             |    2 +-\n t/t1450-fsck.sh               |    6 +-----\n t/t6050-replace.sh            |    2 +-\n 7 files changed, 14 insertions(+), 28 deletions(-)\n\ndiff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt\nindex 6c47395..199c5a0 100644\n--- a/Documentation/git-fsck.txt\n+++ b/Documentation/git-fsck.txt\n@@ -30,6 +30,9 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless\n \tPrint out objects that exist but that aren't reachable from any\n \tof the reference nodes.\n \n+--dangling::\n+\tPrint objects that exist but that are never 'directly' used.\n+\n --root::\n \tReport root nodes.\n \ndiff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt\nindex 40af321..4c1aff6 100644\n--- a/Documentation/git-repack.txt\n+++ b/Documentation/git-repack.txt\n@@ -34,7 +34,7 @@ OPTIONS\n \tEspecially useful when packing a repository that is used\n \tfor private development. Use\n \twith '-d'.  This will clean up the objects that `git prune`\n-\tleaves behind, but `git fsck --full` shows as\n+\tleaves behind, but `git fsck --full --dangling` shows as\n \tdangling.\n +\n Note that users fetching over dumb protocols will have to fetch the\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex f13a846..09ffbcc 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -1582,25 +1582,12 @@ Checking the repository for corruption\n \n The linkgit:git-fsck[1] command runs a number of self-consistency checks\n on the repository, and reports on any problems.  This may take some\n-time.  The most common warning by far is about \"dangling\" objects:\n+time.\n \n -------------------------------------------------\n $ git fsck\n-dangling commit 7281251ddd2a61e38657c827739c57015671a6b3\n-dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63\n-dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5\n-dangling blob 218761f9d90712d37a9c5e36f406f92202db07eb\n-dangling commit bf093535a34a4d35731aa2bd90fe6b176302f14f\n-dangling commit 8e4bec7f2ddaa268bef999853c25755452100f8e\n-dangling tree d50bb86186bf27b681d25af89d3b5b68382e4085\n-dangling tree b24c2473f1fd3d91352a624795be026d64c8841f\n-...\n -------------------------------------------------\n \n-Dangling objects are not a problem.  At worst they may take up a little\n-extra disk space.  They can sometimes provide a last-resort method for\n-recovering lost work--see <<dangling-objects>> for details.\n-\n [[recovering-lost-changes]]\n Recovering lost changes\n ~~~~~~~~~~~~~~~~~~~~~~~\n@@ -1665,7 +1652,7 @@ commits in the dangling objects that `git fsck` reports.  See\n <<dangling-objects>> for the details.\n \n -------------------------------------------------\n-$ git fsck\n+$ git fsck --dangling\n dangling commit 7281251ddd2a61e38657c827739c57015671a6b3\n dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63\n dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5\n@@ -3301,9 +3288,6 @@ broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n missing blob 4b9458b3786228369c63936db65827de3cc06200\n ------------------------------------------------\n \n-(Typically there will be some \"dangling object\" messages too, but they\n-aren't interesting.)\n-\n Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6\n points to it.  If you could find just one copy of that missing blob\n object, possibly in some other repository, you could move it into\ndiff --git a/builtin/fsck.c b/builtin/fsck.c\nindex 8c479a7..0745535 100644\n--- a/builtin/fsck.c\n+++ b/builtin/fsck.c\n@@ -29,6 +29,7 @@ static int errors_found;\n static int write_lost_and_found;\n static int verbose;\n static int show_progress = -1;\n+static int show_dangling;\n #define ERROR_OBJECT 01\n #define ERROR_REACHABLE 02\n #define ERROR_PACK 04\n@@ -221,8 +222,9 @@ static void check_unreachable_object(struct object *obj)\n \t * start looking at, for example.\n \t */\n \tif (!obj->used) {\n-\t\tprintf(\"dangling %s %s\\n\", typename(obj->type),\n-\t\t       sha1_to_hex(obj->sha1));\n+\t\tif (show_dangling)\n+\t\t\tprintf(\"dangling %s %s\\n\", typename(obj->type),\n+\t\t\t       sha1_to_hex(obj->sha1));\n \t\tif (write_lost_and_found) {\n \t\t\tchar *filename = git_path(\"lost-found/%s/%s\",\n \t\t\t\tobj->type == OBJ_COMMIT ? \"commit\" : \"other\",\n@@ -614,6 +616,7 @@ static char const * const fsck_usage[] = {\n static struct option fsck_opts[] = {\n \tOPT__VERBOSE(&verbose, \"be verbose\"),\n \tOPT_BOOLEAN(0, \"unreachable\", &show_unreachable, \"show unreachable objects\"),\n+\tOPT_BOOLEAN(0, \"dangling\", &show_dangling, \"show dangling objects\"),\n \tOPT_BOOLEAN(0, \"tags\", &show_tags, \"report tags\"),\n \tOPT_BOOLEAN(0, \"root\", &show_root, \"report root nodes\"),\n \tOPT_BOOLEAN(0, \"cache\", &keep_cache_objects, \"make index objects head nodes\"),\ndiff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh\nindex 252fc82..12441c5 100755\n--- a/t/t1410-reflog.sh\n+++ b/t/t1410-reflog.sh\n@@ -20,7 +20,7 @@ check_have () {\n }\n \n check_fsck () {\n-\toutput=$(git fsck --full)\n+\toutput=$(git fsck --full --dangling)\n \tcase \"$1\" in\n \t'')\n \t\ttest -z \"$output\" ;;\ndiff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh\nindex 523ce9c..78bfbc3 100755\n--- a/t/t1450-fsck.sh\n+++ b/t/t1450-fsck.sh\n@@ -27,12 +27,8 @@ test_expect_success 'loose objects borrowed from alternate are not missing' '\n \t\tgit init &&\n \t\techo ../../../.git/objects >.git/objects/info/alternates &&\n \t\ttest_commit C fileC one &&\n-\t\tgit fsck >../out 2>&1\n+\t\tgit fsck >../actual 2>&1\n \t) &&\n-\t{\n-\t\tgrep -v dangling out >actual ||\n-\t\t:\n-\t} &&\n \ttest_cmp empty actual\n '\n \ndiff --git a/t/t6050-replace.sh b/t/t6050-replace.sh\nindex 5c87f28..5b36ee3 100755\n--- a/t/t6050-replace.sh\n+++ b/t/t6050-replace.sh\n@@ -95,7 +95,7 @@ test_expect_success 'tag replaced commit' '\n '\n \n test_expect_success '\"git fsck\" works' '\n-     git fsck master > fsck_master.out &&\n+     git fsck --dangling master > fsck_master.out &&\n      grep \"dangling commit $R\" fsck_master.out &&\n      grep \"dangling tag $(cat .git/refs/tags/mytag)\" fsck_master.out &&\n      test -z \"$(git fsck)\"\n-- \n1.7.9.1\n"},{"id":"185470","messageId":"7vty2ddzqj.fsf@alter.siamese.dyndns.org","threadId":"29748","inReplyTo":"20120226204357.GA26088@ecki","subject":"Re: [PATCH] fsck: do not print dangling objects by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-26T21:57:40Z","receivedAt":"2012-02-26T21:57:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Clemens Buchacher <drizzd@aon.at> writes:\n\n> Every reference to git fsck that I could find in the documentation or on\n> the web is followed by the some kind of assurance that dangling objects\n> are \"not a problem\", \"nothing to worry about\" or \"not at all\n> interesting\".\n>\n> Instead of telling the user everywhere to ignore those messages, let's\n> not print them in the first place. The --dangling flag can be used to\n> explicitly enable printing dangling objects.\n>\n> Signed-off-by: Clemens Buchacher <drizzd@aon.at>\n\nThanks.\n\nI think that both the ultimate goal explained above, and the direction in\nwhich the documentation updates tries to move us, are good.  I only gave a\ncursory look at the code changes, but what they implement seems to match\nthe intention.\n\nOf course I may be missing something, so objections from others to argue\nwhy we shouldn't do this is very much welcomed to stop me and Clemens ;-).\n\n> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> index f13a846..09ffbcc 100644\n> --- a/Documentation/user-manual.txt\n> +++ b/Documentation/user-manual.txt\n> @@ -1582,25 +1582,12 @@ Checking the repository for corruption\n>  \n>  The linkgit:git-fsck[1] command runs a number of self-consistency checks\n>  on the repository, and reports on any problems.  This may take some\n> +time.\n>  ...\n> -Dangling objects are not a problem.  At worst they may take up a little\n> -extra disk space.  They can sometimes provide a last-resort method for\n> -recovering lost work--see <<dangling-objects>> for details.\n\nLosing this description is not a problem and is indeed an improvement in\nthis section in the user manual, but let's make a mental note that the\nuser needs to also learn what the third sentence says elsewhere in this\ndocument.\n\n << reads on >>\n\n> @@ -1665,7 +1652,7 @@ commits in the dangling objects that `git fsck` reports.  See\n>  <<dangling-objects>> for the details.\n>  \n>  -------------------------------------------------\n> -$ git fsck\n> +$ git fsck --dangling\n>  dangling commit 7281251ddd2a61e38657c827739c57015671a6b3\n>  dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63\n>  dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5\n> @@ -3301,9 +3288,6 @@ broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n>  missing blob 4b9458b3786228369c63936db65827de3cc06200\n>  ------------------------------------------------\n>  \n> -(Typically there will be some \"dangling object\" messages too, but they\n> -aren't interesting.)\n> -\n\nThe old sentence becomes stale as the example _explicitly_ asks the\ncommand to show the dangling ones.\n\n>  Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6\n>  points to it.  If you could find just one copy of that missing blob\n>  object, possibly in some other repository, you could move it into\n\nAnd this part, together with the introductory text of the section (not\nshown in the context), says what the \"third sentence\" above wanted to say.\n\nSo overall I think this is a vast improvement without losing any\ninformation or clarity.\n\nNice.\n"},{"id":"185473","messageId":"7vhayddxgp.fsf@alter.siamese.dyndns.org","threadId":"29748","inReplyTo":"7vty2ddzqj.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] fsck: do not print dangling objects by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-26T22:46:46Z","receivedAt":"2012-02-26T22:46:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I think that both the ultimate goal explained above, and the direction in\n> which the documentation updates tries to move us, are good.  I only gave a\n> cursory look at the code changes, but what they implement seems to match\n> the intention.\n>\n> Of course I may be missing something, so objections from others to argue\n> why we shouldn't do this is very much welcomed to stop me and Clemens ;-).\n\nLet's start with the obvious.\n\nIt is much easier for a user to use a new option on the command line when\nhe wants to use an improved behaviour when he runs the command manually.\nHaving to update scripts that run the command to act on its output, on the\nother hand, is much more painful to the users.\n\nAnd the intended audience for this change clearly is interactive users\nthat follow the user-manual to try things out.\n\nGiven that, isn't it not just sufficient but actually better to instead\nadd a new --no-dangling option and keep the default unchanged?\n"},{"id":"185494","messageId":"4F4B25D8.8040803@in.waw.pl","threadId":"29748","inReplyTo":"7vhayddxgp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] fsck: do not print dangling objects by default","fromName":"Zbigniew Jędrzejewski-Szmek","fromEmail":"zbyszek@in.waw.pl","sentAt":"2012-02-27T06:42:32Z","receivedAt":"2012-02-27T06:42:32Z","isPatch":true,"sender":{"key":"zbyszek@in.waw.pl","avatar":"https://avatars.githubusercontent.com/u/349618?v=4"},"body":"On 02/26/2012 11:46 PM, Junio C Hamano wrote:\n> Junio C Hamano<gitster@pobox.com>  writes:\n>\n>> I think that both the ultimate goal explained above, and the direction in\n>> which the documentation updates tries to move us, are good.  I only gave a\n>> cursory look at the code changes, but what they implement seems to match\n>> the intention.\n>>\n>> Of course I may be missing something, so objections from others to argue\n>> why we shouldn't do this is very much welcomed to stop me and Clemens ;-).\n>\n> Let's start with the obvious.\n>\n> It is much easier for a user to use a new option on the command line when\n> he wants to use an improved behaviour when he runs the command manually.\n> Having to update scripts that run the command to act on its output, on the\n> other hand, is much more painful to the users.\n>\n> And the intended audience for this change clearly is interactive users\n> that follow the user-manual to try things out.\n>\n> Given that, isn't it not just sufficient but actually better to instead\n> add a new --no-dangling option and keep the default unchanged?\n\nI understood the goal of this change as \"modify fsck output to not show \nconfusing 'dangling' messages by default. Not when running the tutorial \nand having the output explained in parallel, but when someone runs \ngit-fsck to clean up the repository. In that situation, if somebody \nknows enough to run --no-dangling, than they know enough to ignore the \n'dangling' messages in the output.\n\nFor the knowledgeable user, --no-dangling could be useful to avoid \nuninteresting messages which usually dwarf the rest of output, but this \nwould be less important.\n\nZbyszek\n"},{"id":"185546","messageId":"20120227191846.GB1600@sigill.intra.peff.net","threadId":"29748","inReplyTo":"7vhayddxgp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] fsck: do not print dangling objects by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-27T19:18:46Z","receivedAt":"2012-02-27T19:18:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 26, 2012 at 02:46:46PM -0800, Junio C Hamano wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > I think that both the ultimate goal explained above, and the direction in\n> > which the documentation updates tries to move us, are good.  I only gave a\n> > cursory look at the code changes, but what they implement seems to match\n> > the intention.\n> >\n> > Of course I may be missing something, so objections from others to argue\n> > why we shouldn't do this is very much welcomed to stop me and Clemens ;-).\n> \n> Let's start with the obvious.\n> \n> It is much easier for a user to use a new option on the command line when\n> he wants to use an improved behaviour when he runs the command manually.\n> Having to update scripts that run the command to act on its output, on the\n> other hand, is much more painful to the users.\n> \n> And the intended audience for this change clearly is interactive users\n> that follow the user-manual to try things out.\n> \n> Given that, isn't it not just sufficient but actually better to instead\n> add a new --no-dangling option and keep the default unchanged?\n\nBut if your intended audience is users who are confused by the dangling\nwarnings, explaining to them to use --no-dangling is not really\nimproving the situation. Of course, it is fsck, so I wonder how often\nclueless people are really running it in the first place (i.e., it is\nnot and should not be part of most users' typical workflows). If it is\nsimply the case that they are being told to run \"git fsck\" by more\nexpert users without understanding what it does, then I could buy the\nargument that those expert users could just as easily say \"git fsck\n--no-dangling\".\n\n-Peff\n"},{"id":"185548","messageId":"7vr4xg6pn2.fsf@alter.siamese.dyndns.org","threadId":"29748","inReplyTo":"20120227191846.GB1600@sigill.intra.peff.net","subject":"Re: [PATCH] fsck: do not print dangling objects by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-27T19:29:53Z","receivedAt":"2012-02-27T19:29:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> Given that, isn't it not just sufficient but actually better to instead\n>> add a new --no-dangling option and keep the default unchanged?\n>\n> ... Of course, it is fsck, so I wonder how often clueless people are\n> really running it in the first place (i.e., it is not and should not be\n> part of most users' typical workflows). If it is simply the case that\n> they are being told to run \"git fsck\" by more expert users without\n> understanding what it does, then I could buy the argument that those\n> expert users could just as easily say \"git fsck --no-dangling\".\n\nYes, that was certainly part of my pros-and-cons analysis.  If you run\n\"git fsck\" without \"--no-dangling\" without reading the manual, you may\nget confused, but that is *not* the primary audience.  People who are\ncurious can read the manual and figure it out, and the need for \"fsck\" is\nmuch rarer these days, compared to 2005 ;-)\n\nIn that context, only large downsides of potentially breaking and having\nto adjust existing scripts remains without much upsides, if we were to\nswitch the default.\n"},{"id":"185564","messageId":"20120227211316.GA29081@ecki","threadId":"29748","inReplyTo":"7vr4xg6pn2.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] fsck: do not print dangling objects by default","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-02-27T21:13:16Z","receivedAt":"2012-02-27T21:13:16Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Mon, Feb 27, 2012 at 11:29:53AM -0800, Junio C Hamano wrote:\n> Jeff King <peff@peff.net> writes:\n> \n> >> Given that, isn't it not just sufficient but actually better to instead\n> >> add a new --no-dangling option and keep the default unchanged?\n> >\n> > ... Of course, it is fsck, so I wonder how often clueless people are\n> > really running it in the first place (i.e., it is not and should not be\n> > part of most users' typical workflows). If it is simply the case that\n> > they are being told to run \"git fsck\" by more expert users without\n> > understanding what it does, then I could buy the argument that those\n> > expert users could just as easily say \"git fsck --no-dangling\".\n> \n> Yes, that was certainly part of my pros-and-cons analysis.  If you run\n> \"git fsck\" without \"--no-dangling\" without reading the manual, you may\n> get confused, but that is *not* the primary audience.\n\nIt is not my only concern that users might be confused. I believe the\ncommand prints a lot of useless messages, which is by itself a UI\ndeficiency. But even worse, those numerous messages tend to hide an\nactual problem in a long scrollback buffer. Sometimes my scrollback\nbuffer is not even large enough and I have to re-run fsck (which is not\nexactly a fast command), just so I can grep out the dangling blobs.\n\n> People who are curious can read the manual and figure it out, and the\n> need for \"fsck\" is much rarer these days, compared to 2005 ;-)\n\nIn my opinion, the need for fsck is much more common these days. With\nthe alternates feature, it happens all the time that a repository breaks\nif one is not extremely careful.\n\n> In that context, only large downsides of potentially breaking and having\n> to adjust existing scripts remains without much upsides, if we were to\n> switch the default.\n\nThere is something wrong with weighting a UI improvement against\nconvenient use in scripts. If that were the issue, then we should add a\nplumbing version for all commands, like we do for git status\n--porcelain. Otherwise we can never change anything any more.\n"},{"id":"185567","messageId":"20120227213304.GB19779@sigill.intra.peff.net","threadId":"29748","inReplyTo":"20120227211316.GA29081@ecki","subject":"Re: [PATCH] fsck: do not print dangling objects by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-27T21:33:04Z","receivedAt":"2012-02-27T21:33:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 27, 2012 at 10:13:16PM +0100, Clemens Buchacher wrote:\n\n> > Yes, that was certainly part of my pros-and-cons analysis.  If you run\n> > \"git fsck\" without \"--no-dangling\" without reading the manual, you may\n> > get confused, but that is *not* the primary audience.\n> \n> It is not my only concern that users might be confused. I believe the\n> command prints a lot of useless messages, which is by itself a UI\n> deficiency. But even worse, those numerous messages tend to hide an\n> actual problem in a long scrollback buffer. Sometimes my scrollback\n> buffer is not even large enough and I have to re-run fsck (which is not\n> exactly a fast command), just so I can grep out the dangling blobs.\n\nYeah, but doesn't adding \"--no-dangling\" solve that issue?\n\n> > People who are curious can read the manual and figure it out, and the\n> > need for \"fsck\" is much rarer these days, compared to 2005 ;-)\n> \n> In my opinion, the need for fsck is much more common these days. With\n> the alternates feature, it happens all the time that a repository breaks\n> if one is not extremely careful.\n\nInteresting. I can't remember the last time I ran fsck. But I am not the\nonly git user, and my assumptions are only based on my own experience,\nnot other data.\n\n> > In that context, only large downsides of potentially breaking and having\n> > to adjust existing scripts remains without much upsides, if we were to\n> > switch the default.\n> \n> There is something wrong with weighting a UI improvement against\n> convenient use in scripts. If that were the issue, then we should add a\n> plumbing version for all commands, like we do for git status\n> --porcelain. Otherwise we can never change anything any more.\n\nI don't think it's convenience as much as scripts which try to detect\ndangling by using \"git fsck\" will now be broken with a really bad\nfailure mode (i.e., they used to run \"git fsck\" and parse the dangling\nlines on stderr, but now they will erroneously think that nothing is\ndangling!).\n\nIf we really care about that, then the right answer is our usual:\n\n  1. Introduce --dangling/--no-dangling, leaving the default.\n\n  2. Wait a while until the features are well-established.\n\n  3. Scripts adapt to use --dangling if they want it.\n\n  4. Wait a while for scripts to be updated.\n\n  5. Flip the default to --no-dangling.\n\nI wrote but didn't send in my last email a long analysis of why it is\nwrong to combine fsck's default mode of operation (which is really about\n\"is this repository corrupted or broken\") with checking for dangling\nobjects (which is something you do when you are looking for lost work).\nBut I don't think that is even really up for debate. If we were\ndesigning fsck from scratch, I think everybody in the thread has the\nfeeling that reporting dangling by default is wrong. And we should\ndefinitely add \"--no-dangling\" to address that.\n\nBut flipping the default is a different story, and that has to weigh the\npotential breakage above versus having a good UI. I'm on the fence about\nwhether the above is a big enough problem to care about (mostly because\nI'm not sure anybody has actually written such a script).\n\n-Peff\n"},{"id":"185568","messageId":"7vhayc55a7.fsf@alter.siamese.dyndns.org","threadId":"29748","inReplyTo":"20120227211316.GA29081@ecki","subject":"Re: [PATCH] fsck: do not print dangling objects by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-27T21:34:56Z","receivedAt":"2012-02-27T21:34:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Clemens Buchacher <drizzd@aon.at> writes:\n\n> There is something wrong with weighting a UI improvement against\n> convenient use in scripts. If that were the issue, then ...\n\nBut that is not the issue.  Nobody said anything about convenience for\nscript writers.\n\nI am talking about regressions to already written long time ago and used\nby many people _without_ them having to worry about how it internally\nworks.  By switching the default, you are suddenly making them worry about\nit again.\n"},{"id":"185577","messageId":"20120227221820.GA1194@ecki","threadId":"29748","inReplyTo":"20120227213304.GB19779@sigill.intra.peff.net","subject":"Re: [PATCH] fsck: do not print dangling objects by default","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-02-27T22:18:24Z","receivedAt":"2012-02-27T22:18:24Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Mon, Feb 27, 2012 at 04:33:04PM -0500, Jeff King wrote:\n> On Mon, Feb 27, 2012 at 10:13:16PM +0100, Clemens Buchacher wrote:\n> \n> > > Yes, that was certainly part of my pros-and-cons analysis.  If you run\n> > > \"git fsck\" without \"--no-dangling\" without reading the manual, you may\n> > > get confused, but that is *not* the primary audience.\n> > \n> > It is not my only concern that users might be confused. I believe the\n> > command prints a lot of useless messages, which is by itself a UI\n> > deficiency. But even worse, those numerous messages tend to hide an\n> > actual problem in a long scrollback buffer. Sometimes my scrollback\n> > buffer is not even large enough and I have to re-run fsck (which is not\n> > exactly a fast command), just so I can grep out the dangling blobs.\n> \n> Yeah, but doesn't adding \"--no-dangling\" solve that issue?\n\nI can just as well use grep -v ^dangling.\n"},{"id":"185683","messageId":"7v7gz6y1zz.fsf_-_@alter.siamese.dyndns.org","threadId":"29748","inReplyTo":"7vhayc55a7.fsf@alter.siamese.dyndns.org","subject":"[PATCH] fsck: --no-dangling omits \"dangling object\" information","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-28T23:25:20Z","receivedAt":"2012-02-28T23:25:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The default output from \"fsck\" is often overwhelmed by informational\nmessage on dangling objects, especially if you do not repack often, and a\nreal error can easily be buried.\n\nAdd \"--no-dangling\" option to omit them, and update the user manual to\ndemonstrate its use.\n\nBased on a patch by Clemens Buchacher, but reverted the part to change\nthe default to --no-dangling, which is unsuitable for the first patch.\nThe usual three-step procedure to break the backward compatibility over\ntime needs to happen on top of this, if we were to go in that direction.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n * I butchered Clemens's patch and added \"--no-dangling\", and reverted the\n   part that flips the default.  I also took the authorship blame, as I do\n   not share the final goal of fliping the default (yet), but our first\n   steps should be in the same direction, which is this patch.\n\n Documentation/git-fsck.txt    |    7 ++++++-\n Documentation/git-repack.txt  |    2 +-\n Documentation/user-manual.txt |   15 +++++++--------\n builtin/fsck.c                |    7 +++++--\n t/t1450-fsck.sh               |    6 +-----\n 5 files changed, 20 insertions(+), 17 deletions(-)\n\ndiff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt\nindex 6c47395..47e2f19 100644\n--- a/Documentation/git-fsck.txt\n+++ b/Documentation/git-fsck.txt\n@@ -11,7 +11,7 @@ SYNOPSIS\n [verse]\n 'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]\n \t [--[no-]full] [--strict] [--verbose] [--lost-found]\n-\t [--[no-]progress] [<object>*]\n+\t [--[no-]dangling] [--[no-]progress] [<object>*]\n \n DESCRIPTION\n -----------\n@@ -30,6 +30,11 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless\n \tPrint out objects that exist but that aren't reachable from any\n \tof the reference nodes.\n \n+--dangling::\n+--no-dangling::\n+\tPrint objects that exist but that are never 'directly' used (default).\n+\t`--no-dangling` can be used to squech this information from the output.\n+\n --root::\n \tReport root nodes.\n \ndiff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt\nindex 40af321..4c1aff6 100644\n--- a/Documentation/git-repack.txt\n+++ b/Documentation/git-repack.txt\n@@ -34,7 +34,7 @@ OPTIONS\n \tEspecially useful when packing a repository that is used\n \tfor private development. Use\n \twith '-d'.  This will clean up the objects that `git prune`\n-\tleaves behind, but `git fsck --full` shows as\n+\tleaves behind, but `git fsck --full --dangling` shows as\n \tdangling.\n +\n Note that users fetching over dumb protocols will have to fetch the\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex f13a846..6c7fee7 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -1582,7 +1582,7 @@ Checking the repository for corruption\n \n The linkgit:git-fsck[1] command runs a number of self-consistency checks\n on the repository, and reports on any problems.  This may take some\n-time.  The most common warning by far is about \"dangling\" objects:\n+time.\n \n -------------------------------------------------\n $ git fsck\n@@ -1597,9 +1597,11 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f\n ...\n -------------------------------------------------\n \n-Dangling objects are not a problem.  At worst they may take up a little\n-extra disk space.  They can sometimes provide a last-resort method for\n-recovering lost work--see <<dangling-objects>> for details.\n+You will see informational messages on dangling objects. They are objects\n+that still exist in the repository but are no longer referenced by any of\n+your branches, and can (and will) be removed after a while with \"gc\".\n+You can run `git fsck --no-dangling` to supress these messages, and still\n+view real errors.\n \n [[recovering-lost-changes]]\n Recovering lost changes\n@@ -3295,15 +3297,12 @@ it is with linkgit:git-fsck[1]; this may be time-consuming.\n Assume the output looks like this:\n \n ------------------------------------------------\n-$ git fsck --full\n+$ git fsck --full --no-dangling\n broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8\n               to    blob 4b9458b3786228369c63936db65827de3cc06200\n missing blob 4b9458b3786228369c63936db65827de3cc06200\n ------------------------------------------------\n \n-(Typically there will be some \"dangling object\" messages too, but they\n-aren't interesting.)\n-\n Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6\n points to it.  If you could find just one copy of that missing blob\n object, possibly in some other repository, you could move it into\ndiff --git a/builtin/fsck.c b/builtin/fsck.c\nindex 8c479a7..67eb553 100644\n--- a/builtin/fsck.c\n+++ b/builtin/fsck.c\n@@ -29,6 +29,7 @@ static int errors_found;\n static int write_lost_and_found;\n static int verbose;\n static int show_progress = -1;\n+static int show_dangling = 1;\n #define ERROR_OBJECT 01\n #define ERROR_REACHABLE 02\n #define ERROR_PACK 04\n@@ -221,8 +222,9 @@ static void check_unreachable_object(struct object *obj)\n \t * start looking at, for example.\n \t */\n \tif (!obj->used) {\n-\t\tprintf(\"dangling %s %s\\n\", typename(obj->type),\n-\t\t       sha1_to_hex(obj->sha1));\n+\t\tif (show_dangling)\n+\t\t\tprintf(\"dangling %s %s\\n\", typename(obj->type),\n+\t\t\t       sha1_to_hex(obj->sha1));\n \t\tif (write_lost_and_found) {\n \t\t\tchar *filename = git_path(\"lost-found/%s/%s\",\n \t\t\t\tobj->type == OBJ_COMMIT ? \"commit\" : \"other\",\n@@ -614,6 +616,7 @@ static char const * const fsck_usage[] = {\n static struct option fsck_opts[] = {\n \tOPT__VERBOSE(&verbose, \"be verbose\"),\n \tOPT_BOOLEAN(0, \"unreachable\", &show_unreachable, \"show unreachable objects\"),\n+\tOPT_BOOL(0, \"dangling\", &show_dangling, \"show dangling objects\"),\n \tOPT_BOOLEAN(0, \"tags\", &show_tags, \"report tags\"),\n \tOPT_BOOLEAN(0, \"root\", &show_root, \"report root nodes\"),\n \tOPT_BOOLEAN(0, \"cache\", &keep_cache_objects, \"make index objects head nodes\"),\ndiff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh\nindex 5b8ebd8..5b79c51 100755\n--- a/t/t1450-fsck.sh\n+++ b/t/t1450-fsck.sh\n@@ -27,12 +27,8 @@ test_expect_success 'loose objects borrowed from alternate are not missing' '\n \t\tgit init &&\n \t\techo ../../../.git/objects >.git/objects/info/alternates &&\n \t\ttest_commit C fileC one &&\n-\t\tgit fsck >../out 2>&1\n+\t\tgit fsck --no-dangling >../actual 2>&1\n \t) &&\n-\t{\n-\t\tgrep -v dangling out >actual ||\n-\t\t:\n-\t} &&\n \ttest_cmp empty actual\n '\n \n-- \n1.7.9.2.344.g3e8c86\n"}]}