{"thread":{"id":"7504","subject":"fsck missing dangling commits that are candidate heads?","startedAt":"2007-04-03T19:41:26Z","lastAt":"2007-04-04T20:08:45Z","messageCount":7,"participants":["Sergio Callegari","Shawn O. Pearce","Nicolas Pitre"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"38522","messageId":"loom.20070403T213135-68@post.gmane.org","threadId":"7504","inReplyTo":null,"subject":"fsck missing dangling commits that are candidate heads?","fromName":"Sergio Callegari","fromEmail":"scallegari@arces.unibo.it","sentAt":"2007-04-03T19:41:26Z","receivedAt":"2007-04-03T19:41:26Z","isPatch":false,"sender":{"key":"scallegari@arces.unibo.it","avatar":null},"body":"Hi,\n\non git 1.5.0.6, I have done the following:\n\nwork work\n\ngit commit -a\n\ngit reset HEAD^         (assume a mistake)\n\ngit fsck\n\nthe last fsck shows nothing...\nIs this correct? Shouldn't the latest commit (the one made unreachable by the\nreset) be reported as dangling and as a candidate branch head?\n\nAlso git lost-found misses the commit...\nBut it is there... I can find it manually in the object database and tag it.\n\nAnd finally...\n\nAlso git gc --prune seems to miss the commit... so when we gc useless objects\nappear to be kept around.\n\nIs this correct?\n\nThanks,\n\nSergio\n"},{"id":"38524","messageId":"20070403194750.GG27706@spearce.org","threadId":"7504","inReplyTo":"loom.20070403T213135-68@post.gmane.org","subject":"Re: fsck missing dangling commits that are candidate heads?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-04-03T19:47:50Z","receivedAt":"2007-04-03T19:47:50Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sergio Callegari <scallegari@arces.unibo.it> wrote:\n> on git 1.5.0.6, I have done the following:\n> git commit -a\n> git reset HEAD^         (assume a mistake)\n> git fsck\n> \n> the last fsck shows nothing...\n> Is this correct? Shouldn't the latest commit (the one made unreachable by the\n> reset) be reported as dangling and as a candidate branch head?\n> \n> Also git lost-found misses the commit...\n> But it is there... I can find it manually in the object database and tag it.\n> \n> Also git gc --prune seems to miss the commit... so when we gc useless objects\n> appear to be kept around.\n\nRight.  This is the reflog in action.  Your current branch has two\nreflogs, .git/logs/HEAD and .git/logs/refs/heads/$foo, where $foo\nis your current branch name.  Both of these logs mention the commit\nyou are looking for, so they aren't considered dangling garbage,\nnor are they pruneable.\n\nUse `git log -g` or `git log -g $foo` to look at the reflog for\nHEAD and $foo to locate the commit in question.\n\n-- \nShawn.\n"},{"id":"38526","messageId":"alpine.LFD.0.98.0704031551090.28181@xanadu.home","threadId":"7504","inReplyTo":"loom.20070403T213135-68@post.gmane.org","subject":"Re: fsck missing dangling commits that are candidate heads?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-03T19:53:14Z","receivedAt":"2007-04-03T19:53:14Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 3 Apr 2007, Sergio Callegari wrote:\n\n> Hi,\n> \n> on git 1.5.0.6, I have done the following:\n> \n> work work\n> \n> git commit -a\n> \n> git reset HEAD^         (assume a mistake)\n> \n> git fsck\n> \n> the last fsck shows nothing...\n> Is this correct?\n\nYes.\n\n> Shouldn't the latest commit (the one made unreachable by the\n> reset) be reported as dangling and as a candidate branch head?\n> \n> Also git lost-found misses the commit...\n> But it is there... I can find it manually in the object database and tag it.\n\nIt is not lost.  Try git log -g and you'll probably find it there... at \nleast until the reflog entry corresponding to it gets expired.\n\n\nNicolas\n"},{"id":"38528","messageId":"loom.20070403T215123-220@post.gmane.org","threadId":"7504","inReplyTo":"20070403194750.GG27706@spearce.org","subject":"Re: fsck missing dangling commits that are candidate heads?","fromName":"Sergio Callegari","fromEmail":"scallegari@arces.unibo.it","sentAt":"2007-04-03T19:56:53Z","receivedAt":"2007-04-03T19:56:53Z","isPatch":false,"sender":{"key":"scallegari@arces.unibo.it","avatar":null},"body":"Shawn O. Pearce <spearce <at> spearce.org> writes:\n\n>\n> Right.  This is the reflog in action.  Your current branch has two\n> reflogs, .git/logs/HEAD and .git/logs/refs/heads/$foo, where $foo\n> is your current branch name.  Both of these logs mention the commit\n> you are looking for, so they aren't considered dangling garbage,\n> nor are they pruneable.\n> \n> Use `git log -g` or `git log -g $foo` to look at the reflog for\n> HEAD and $foo to locate the commit in question.\n> \n\nMany thanks! I was quite sure I was missing something...\nAt least I am in good company since the fsck man page does not mention the \nlogs :-)\n\nThen... is there any shorthand for finding candidate branch-heads (i.e. for\nhaving something like fsck without looking at the logs) ?\n"},{"id":"38616","messageId":"loom.20070404T152916-290@post.gmane.org","threadId":"7504","inReplyTo":"loom.20070403T215123-220@post.gmane.org","subject":"Re: fsck missing dangling commits that are candidate heads?","fromName":"Sergio Callegari","fromEmail":"scallegari@arces.unibo.it","sentAt":"2007-04-04T13:32:54Z","receivedAt":"2007-04-04T13:32:54Z","isPatch":false,"sender":{"key":"scallegari@arces.unibo.it","avatar":null},"body":"Sergio Callegari <scallegari <at> arces.unibo.it> writes:\n\n \n> Many thanks! I was quite sure I was missing something...\n> At least I am in good company since the fsck man page does not mention the \n> logs \n> \n> Then... is there any shorthand for finding candidate branch-heads (i.e. for\n> having something like fsck without looking at the logs) ?\n> \n\nI mean, so that git lost-found can take advantage of it... in fact git gc is\nsurely doing the right thing by considering reflogs, but probably git lost-found\nshould not (at least wrt its documentation this script appears to be not in its\nbest shape right now).\n\nSergio \n"},{"id":"38621","messageId":"20070404144614.GD4628@spearce.org","threadId":"7504","inReplyTo":"loom.20070404T152916-290@post.gmane.org","subject":"Re: fsck missing dangling commits that are candidate heads?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-04-04T14:46:14Z","receivedAt":"2007-04-04T14:46:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sergio Callegari <scallegari@arces.unibo.it> wrote:\n> I mean, so that git lost-found can take advantage of it... in fact git gc is\n> surely doing the right thing by considering reflogs, but probably git lost-found\n> should not (at least wrt its documentation this script appears to be not in its\n> best shape right now).\n\nNo shorthand, but the following patch might do the trick:\n\n-->8--\n[PATCH] Fix lost-found to show commits only referenced by reflogs\n\nPrior to 1.5.0 the git-lost-found utility was useful to locate\ncommits that were not referenced by any ref.  These were often\namends, or resets, or tips of branches that had been deleted.\nBeing able to locate a 'lost' commit and recover it by creating a\nnew branch was a useful feature in those days.\n\nUnfortunately 1.5.0 added the reflogs to the reachability analysis\nperformed by git-fsck, which means that most commits users would\nconsider to be lost are still reachable through a reflog.  So most\n(or all!) commits are reachable, and nothing gets output from\ngit-lost-found.\n\nNow git-fsck can be told to ignore reflogs during its reachability\nanalysis, making git-lost-found useful again to locate commits\nthat are no longer referenced by a ref itself, but may still be\nreferenced by a reflog.\n\nSigned-off-by: Shawn O. Pearce <spearce@spearce.org>\n---\n Documentation/git-fsck.txt |    8 +++++++-\n builtin-fsck.c             |    8 +++++++-\n git-lost-found.sh          |    2 +-\n 3 files changed, 15 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt\nindex 058009d..8c68cf0 100644\n--- a/Documentation/git-fsck.txt\n+++ b/Documentation/git-fsck.txt\n@@ -9,7 +9,7 @@ git-fsck - Verifies the connectivity and validity of the objects in the database\n SYNOPSIS\n --------\n [verse]\n-'git-fsck' [--tags] [--root] [--unreachable] [--cache]\n+'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]\n \t\t [--full] [--strict] [<object>*]\n \n DESCRIPTION\n@@ -38,6 +38,12 @@ index file and all SHA1 references in .git/refs/* as heads.\n \tConsider any object recorded in the index also as a head node for\n \tan unreachability trace.\n \n+--no-reflogs::\n+\tDo not consider commits that are referenced only by an\n+\tentry in a reflog to be reachable.  This option is meant\n+\tonly to search for commits that used to be in a ref, but\n+\tnow aren't, but are still in that corresponding reflog.\n+\n --full::\n \tCheck not just objects in GIT_OBJECT_DIRECTORY\n \t($GIT_DIR/objects), but also the ones found in alternate\ndiff --git a/builtin-fsck.c b/builtin-fsck.c\nindex 21f1f9e..e467d4b 100644\n--- a/builtin-fsck.c\n+++ b/builtin-fsck.c\n@@ -14,6 +14,7 @@\n static int show_root;\n static int show_tags;\n static int show_unreachable;\n+static int include_reflogs = 1;\n static int check_full;\n static int check_strict;\n static int keep_cache_objects;\n@@ -517,7 +518,8 @@ static int fsck_handle_ref(const char *refname, const unsigned char *sha1, int f\n static void get_default_heads(void)\n {\n \tfor_each_ref(fsck_handle_ref, NULL);\n-\tfor_each_reflog(fsck_handle_reflog, NULL);\n+\tif (include_reflogs)\n+\t\tfor_each_reflog(fsck_handle_reflog, NULL);\n \n \t/*\n \t * Not having any default heads isn't really fatal, but\n@@ -616,6 +618,10 @@ int cmd_fsck(int argc, char **argv, const char *prefix)\n \t\t\tkeep_cache_objects = 1;\n \t\t\tcontinue;\n \t\t}\n+\t\tif (!strcmp(arg, \"--no-reflogs\")) {\n+\t\t\tinclude_reflogs = 0;\n+\t\t\tcontinue;\n+\t\t}\n \t\tif (!strcmp(arg, \"--full\")) {\n \t\t\tcheck_full = 1;\n \t\t\tcontinue;\ndiff --git a/git-lost-found.sh b/git-lost-found.sh\nindex 9360804..58570df 100755\n--- a/git-lost-found.sh\n+++ b/git-lost-found.sh\n@@ -12,7 +12,7 @@ fi\n laf=\"$GIT_DIR/lost-found\"\n rm -fr \"$laf\" && mkdir -p \"$laf/commit\" \"$laf/other\" || exit\n \n-git fsck --full |\n+git fsck --full --no-reflogs |\n while read dangling type sha1\n do\n \tcase \"$dangling\" in\n-- \n1.5.1.rc3.672.gf5329\n\n\n-- \nShawn.\n"},{"id":"38648","messageId":"loom.20070404T220624-219@post.gmane.org","threadId":"7504","inReplyTo":"20070404144614.GD4628@spearce.org","subject":"Re: fsck missing dangling commits that are candidate heads?","fromName":"Sergio Callegari","fromEmail":"scallegari@arces.unibo.it","sentAt":"2007-04-04T20:08:45Z","receivedAt":"2007-04-04T20:08:45Z","isPatch":false,"sender":{"key":"scallegari@arces.unibo.it","avatar":null},"body":"\nThanks Shawn,\n\nthis is actually much better than a shorthand...\n\nSergio \n"}]}