Integrity check

Integrity check

[Kenneth Johansson]

Iwas doing a git pull that ended badly and I thought that just redoing the
command may help but then git thinks everything is just fine.

After a few failed attempts I still have not find a good way to make sure
that everything is indeed correct. What is the suggested commands to do
that ?

--------
Updating from 7705a8792b0fc82fd7d4dd923724606bbfd9fb20 to
1def630a6a49dda5bc89dfbd86656293640456f0 Checking files out...
 100% (6311/6311) done
Fast forward
*** glibc detected *** malloc(): memory corruption: 0x0a703e80 ***
/home/ken/bin/git-merge: line 56: 14121 Aborted                
git-diff-tree -p --stat --summary -M "$head" "$1" 

>git pull
* refs/heads/origin: same as branch 'master' of
/delta/kernel/git/linux-2.6/ Already up-to-date.
[

Re: Integrity check

[Linus Torvalds]

On Wed, 7 Jun 2006, Kenneth Johansson wrote:
>
> Iwas doing a git pull that ended badly and I thought that just redoing the
> command may help but then git thinks everything is just fine.

What happened is that your first pull actually worked fine, but the final 
"git-diff-tree" that shows what the pull actually _did_ ended up 
SIGSEGV'ing.

Subsequent pulls won't SIGSEGV, because they dont' have anything to do any 
more: your state is fine.

I think the SIGSEGV was due to the problem (that Junio already fixed) with 
a corrupted heap due to the "diffstat" doing bad things for renames.

So you probably do want to update your git version, but I don't think 
anything bad actually ever happened, apart from the (a) scare and (b) lack 
of diffstat output after the pull.

> After a few failed attempts I still have not find a good way to make sure
> that everything is indeed correct. What is the suggested commands to do
> that ?

In the future, just do "git fsck-objects --full" if you're nervous. That 
will do a full integrity check.

		Linus

Re: Integrity check

[Linus Torvalds]

On Tue, 6 Jun 2006, Linus Torvalds wrote:
> 
> In the future, just do "git fsck-objects --full" if you're nervous. That 
> will do a full integrity check.

Btw, this can output some scary-sounding "unreachable commit xxxxxx" 
messages or similar, without that actually necessarily being a problem at 
all. Unreachable objects are normal if you've deleted branches, for 
example, or if you rebase (or your upstream rebases, like the "pu" branch 
in the git archive). 

So if you just see a few unreachable objects, doing a "git prune" will get 
rid of them, and they aren't normally any sign of actual trouble.

		Linus

Re: Integrity check

[Dave Jones]

On Wed, Jun 07, 2006 at 12:46:27AM +0200, Kenneth Johansson wrote:

 > *** glibc detected *** malloc(): memory corruption: 0x0a703e80 ***

The last time I saw one of these in git, it turned out to be
due to a bug in glibc.  If you're using Fedora/RHEL, there are
updates available that fix this problem.

		Dave

-- 
http://www.codemonkey.org.uk