fsck missing dangling commits that are candidate heads?

fsck missing dangling commits that are candidate heads?

[Sergio Callegari]

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

Re: fsck missing dangling commits that are candidate heads?

[Shawn O. Pearce]

Sergio Callegari <scallegari@arces.unibo.it> 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.

Re: fsck missing dangling commits that are candidate heads?

[Sergio Callegari]

Shawn O. Pearce <spearce <at> 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) ?

Re: fsck missing dangling commits that are candidate heads?

[Sergio Callegari]

Sergio Callegari <scallegari <at> 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 

Re: fsck missing dangling commits that are candidate heads?

[Shawn O. Pearce]

Sergio Callegari <scallegari@arces.unibo.it> 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 <spearce@spearce.org>
---
 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] [<object>*]
 
 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.

Re: fsck missing dangling commits that are candidate heads?

[Sergio Callegari]

Thanks Shawn,

this is actually much better than a shorthand...

Sergio 

Re: fsck missing dangling commits that are candidate heads?

[Nicolas Pitre]

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