Re: [PATCH-resent] gitk: fix in procedure drawcommits

From: Michele Ballabio <barra_cuda@katamail.com>
Date: Oct 20, 2007, 16:02 UTC
Message-ID: <200710201802.48111.barra_cuda@katamail.com>
In-Reply-To: <18201.54648.707559.480169@cargo.ozlabs.ibm.com>

[Rocco Rutte added on CC:, since he wrote the hg-fast-export scripts]

On Saturday 20 October 2007, Paul Mackerras wrote:

> Well no.  I'd rather understand why this is happening, in case the 
> error indicates that I'm not handling a corner case correctly.  Can
> you make a copy of the repo that triggers the bug available to me?

IIRC, I just cloned mutt's hg repo:

  hg clone http://dev.mutt.org/hg/mutt

then imported it in git with the scripts at

  http://repo.or.cz/w/fast-export.git

with

  hg-fast-export.sh -r ../mutt

After that, I've done the usual maintenance repack.

Then, running gitk and keeping pressed pgdown triggers that

	"Error: can't unset..."

window.

Uh-oh. I think I just found the issue. That's probably a bug somewhere in the import (either fast-export or fast-import or the original repo, I don't know), so I'm not sure if gitk should be patched, but since the resulting repo seems correct as far as git is concerned (i.e. git fsck --full --strict doesn't complain), I guess something should be done.

Here is the culprit (or so I think). One of the guilty commits is:

	commit a3b4383d69e0754346578c85ba8ff7c05bd88705
	tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
	parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
	parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
	author Brendan Cully <brendan@kublai.com> 1179646159 -0700
	committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
	
	    Forget SMTP password if authentication fails.
	    Thanks to Gregory Shapiro for the initial patch (I've moved the reset
	    from smtp_auth_sasl up to smtp_auth, and used the account API
	    instead of twiddling account bits by hand). Closes #2872.

This commit (and many others) has two parents, but the two parents have the same hash. So gitk tries to unset the same variable twice, hence the error. At this point, the fix for gitk should be either to check if the parents have the same hash when reading the commit or avoiding to unset two times the same variable.

This explanation makes sense to me, now the problem is: have I messed up the import myself, the scripts/commands used are to blame, or is it entirely the original repo's fault?

Since I've redone the import and the error remains, I guess that's not my fault :)