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

From: Jan Hudec <bulb@ucw.cz>
Date: Oct 20, 2007, 18:35 UTC
Message-ID: <20071020183533.GC8887@efreet.light.src>
In-Reply-To: <200710201802.48111.barra_cuda@katamail.com>

On Sat, Oct 20, 2007 at 18:02:47 +0200, Michele Ballabio wrote:

Show 21 quoted lines

> 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
> [...]
> 
> 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.

Judging from the symptoms, I would suspect hg-fast-export. Either mercurial sometimes stores two same hashes instead of the hash and 0 (in which case hg-fast-import should probably be ready to deal with it), or hg-fast-import does something wrong when it sees the 0 parent.

Show 12 quoted lines

> 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 :)

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>