# fsck missing dangling commits that are candidate heads? 7 messages from 2007-04-03 to 2007-04-04. Participants: Sergio Callegari, Shawn O. Pearce, Nicolas Pitre. Thread: https://gitlist.dev/t/7504 ## Sergio Callegari, 2007-04-03 19:41 Subject: fsck missing dangling commits that are candidate heads? Message-ID: URL: https://gitlist.dev/e/loom.20070403T213135-68%40post.gmane.org ``` Hi, on git 1.5.0.6, I have done the following: work work git commit -a git reset HEAD^ (assume a mistake) git fsck the last fsck shows nothing... Is this correct? Shouldn't the latest commit (the one made unreachable by the reset) be reported as dangling and as a candidate branch head? Also git lost-found misses the commit... But it is there... I can find it manually in the object database and tag it. And finally... Also git gc --prune seems to miss the commit... so when we gc useless objects appear to be kept around. Is this correct? Thanks, Sergio ``` ## Shawn O. Pearce, 2007-04-03 19:47 Subject: Re: fsck missing dangling commits that are candidate heads? Message-ID: <20070403194750.GG27706@spearce.org> URL: https://gitlist.dev/e/20070403194750.GG27706%40spearce.org In-Reply-To: ``` Sergio Callegari wrote: > on git 1.5.0.6, I have done the following: > git commit -a > git reset HEAD^ (assume a mistake) > git fsck > > the last fsck shows nothing... > Is this correct? Shouldn't the latest commit (the one made unreachable by the > reset) be reported as dangling and as a candidate branch head? > > Also git lost-found misses the commit... > But it is there... I can find it manually in the object database and tag it. > > Also git gc --prune seems to miss the commit... so when we gc useless objects > appear to be kept around. Right. This is the reflog in action. Your current branch has two reflogs, .git/logs/HEAD and .git/logs/refs/heads/$foo, where $foo is your current branch name. Both of these logs mention the commit you are looking for, so they aren't considered dangling garbage, nor are they pruneable. Use `git log -g` or `git log -g $foo` to look at the reflog for HEAD and $foo to locate the commit in question. -- Shawn. ``` ## Nicolas Pitre, 2007-04-03 19:53 Subject: Re: fsck missing dangling commits that are candidate heads? Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.98.0704031551090.28181%40xanadu.home In-Reply-To: ``` On Tue, 3 Apr 2007, Sergio Callegari wrote: > Hi, > > on git 1.5.0.6, I have done the following: > > work work > > git commit -a > > git reset HEAD^ (assume a mistake) > > git fsck > > the last fsck shows nothing... > Is this correct? Yes. > Shouldn't the latest commit (the one made unreachable by the > reset) be reported as dangling and as a candidate branch head? > > Also git lost-found misses the commit... > But it is there... I can find it manually in the object database and tag it. It is not lost. Try git log -g and you'll probably find it there... at least until the reflog entry corresponding to it gets expired. Nicolas ``` ## Sergio Callegari, 2007-04-03 19:56 Subject: Re: fsck missing dangling commits that are candidate heads? Message-ID: URL: https://gitlist.dev/e/loom.20070403T215123-220%40post.gmane.org In-Reply-To: <20070403194750.GG27706@spearce.org> ``` Shawn O. Pearce spearce.org> writes: > > Right. This is the reflog in action. Your current branch has two > reflogs, .git/logs/HEAD and .git/logs/refs/heads/$foo, where $foo > is your current branch name. Both of these logs mention the commit > you are looking for, so they aren't considered dangling garbage, > nor are they pruneable. > > Use `git log -g` or `git log -g $foo` to look at the reflog for > HEAD and $foo to locate the commit in question. > Many thanks! I was quite sure I was missing something... At least I am in good company since the fsck man page does not mention the logs :-) Then... is there any shorthand for finding candidate branch-heads (i.e. for having something like fsck without looking at the logs) ? ``` ## Sergio Callegari, 2007-04-04 13:32 Subject: Re: fsck missing dangling commits that are candidate heads? Message-ID: URL: https://gitlist.dev/e/loom.20070404T152916-290%40post.gmane.org In-Reply-To: ``` Sergio Callegari arces.unibo.it> writes: > Many thanks! I was quite sure I was missing something... > At least I am in good company since the fsck man page does not mention the > logs > > Then... is there any shorthand for finding candidate branch-heads (i.e. for > having something like fsck without looking at the logs) ? > I mean, so that git lost-found can take advantage of it... in fact git gc is surely doing the right thing by considering reflogs, but probably git lost-found should not (at least wrt its documentation this script appears to be not in its best shape right now). Sergio ``` ## Shawn O. Pearce, 2007-04-04 14:46 Subject: Re: fsck missing dangling commits that are candidate heads? Message-ID: <20070404144614.GD4628@spearce.org> URL: https://gitlist.dev/e/20070404144614.GD4628%40spearce.org In-Reply-To: ``` Sergio Callegari wrote: > I mean, so that git lost-found can take advantage of it... in fact git gc is > surely doing the right thing by considering reflogs, but probably git lost-found > should not (at least wrt its documentation this script appears to be not in its > best shape right now). No shorthand, but the following patch might do the trick: -->8-- [PATCH] Fix lost-found to show commits only referenced by reflogs Prior to 1.5.0 the git-lost-found utility was useful to locate commits that were not referenced by any ref. These were often amends, or resets, or tips of branches that had been deleted. Being able to locate a 'lost' commit and recover it by creating a new branch was a useful feature in those days. Unfortunately 1.5.0 added the reflogs to the reachability analysis performed by git-fsck, which means that most commits users would consider to be lost are still reachable through a reflog. So most (or all!) commits are reachable, and nothing gets output from git-lost-found. Now git-fsck can be told to ignore reflogs during its reachability analysis, making git-lost-found useful again to locate commits that are no longer referenced by a ref itself, but may still be referenced by a reflog. Signed-off-by: Shawn O. Pearce --- Documentation/git-fsck.txt | 8 +++++++- builtin-fsck.c | 8 +++++++- git-lost-found.sh | 2 +- 3 files changed, 15 insertions(+), 3 deletions(-) diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt index 058009d..8c68cf0 100644 --- a/Documentation/git-fsck.txt +++ b/Documentation/git-fsck.txt @@ -9,7 +9,7 @@ git-fsck - Verifies the connectivity and validity of the objects in the database SYNOPSIS -------- [verse] -'git-fsck' [--tags] [--root] [--unreachable] [--cache] +'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] [--full] [--strict] [*] DESCRIPTION @@ -38,6 +38,12 @@ index file and all SHA1 references in .git/refs/* as heads. Consider any object recorded in the index also as a head node for an unreachability trace. +--no-reflogs:: + Do not consider commits that are referenced only by an + entry in a reflog to be reachable. This option is meant + only to search for commits that used to be in a ref, but + now aren't, but are still in that corresponding reflog. + --full:: Check not just objects in GIT_OBJECT_DIRECTORY ($GIT_DIR/objects), but also the ones found in alternate diff --git a/builtin-fsck.c b/builtin-fsck.c index 21f1f9e..e467d4b 100644 --- a/builtin-fsck.c +++ b/builtin-fsck.c @@ -14,6 +14,7 @@ static int show_root; static int show_tags; static int show_unreachable; +static int include_reflogs = 1; static int check_full; static int check_strict; static int keep_cache_objects; @@ -517,7 +518,8 @@ static int fsck_handle_ref(const char *refname, const unsigned char *sha1, int f static void get_default_heads(void) { for_each_ref(fsck_handle_ref, NULL); - for_each_reflog(fsck_handle_reflog, NULL); + if (include_reflogs) + for_each_reflog(fsck_handle_reflog, NULL); /* * Not having any default heads isn't really fatal, but @@ -616,6 +618,10 @@ int cmd_fsck(int argc, char **argv, const char *prefix) keep_cache_objects = 1; continue; } + if (!strcmp(arg, "--no-reflogs")) { + include_reflogs = 0; + continue; + } if (!strcmp(arg, "--full")) { check_full = 1; continue; diff --git a/git-lost-found.sh b/git-lost-found.sh index 9360804..58570df 100755 --- a/git-lost-found.sh +++ b/git-lost-found.sh @@ -12,7 +12,7 @@ fi laf="$GIT_DIR/lost-found" rm -fr "$laf" && mkdir -p "$laf/commit" "$laf/other" || exit -git fsck --full | +git fsck --full --no-reflogs | while read dangling type sha1 do case "$dangling" in -- 1.5.1.rc3.672.gf5329 -- Shawn. ``` ## Sergio Callegari, 2007-04-04 20:08 Subject: Re: fsck missing dangling commits that are candidate heads? Message-ID: URL: https://gitlist.dev/e/loom.20070404T220624-219%40post.gmane.org In-Reply-To: <20070404144614.GD4628@spearce.org> ``` Thanks Shawn, this is actually much better than a shorthand... Sergio ```