On Fri, Aug 10, 2007 at 11:41:08AM -0400, Brian Hetro wrote: > I have a problem with gitk not being able to show one of my > repositories (git version 1.5.3.rc4.41.g7efe). I get this error while > gitk starts: > > can't unset "idinlist(f1d795add789ec43d3ccf1d35f3c39fb464f6e72)": no > such element in array Junio, I did a little digging on this bug, since it was so similar to the duplicate parent errors we were getting a few weeks ago. As it turns out, Brian's repository, generated by hg2git, actually has commit objects with duplicate parents in them. Older versions of git used to remove duplicate parents for all commits, but due to your commits 11d65967 and 1ed84157, we now do it just for history simplification. Which is why he was able to bisect it to 1ed84157, even though it is perhaps not a git bug. So maybe the right attitude is "hg2git should not be generating such broken commits" (or "gitk should not barf on such broken commits" :) ), but I thought I would mention it as an additional data point for those changes. Should git handle duplicate parents of this fashion more robustly? Or should we just assume that they should never have been generated in the first place? -Peff - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html