Re: Bug in gitk: can't unset "idinlist(...) ..."

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Aug 10, 2007, 18:14 UTC
Message-ID: <alpine.LFD.0.999.0708101109310.30176@woody.linux-foundation.org>
In-Reply-To: <20070810173242.GA23628@coredump.intra.peff.net>

On Fri, 10 Aug 2007, Jeff King wrote:

> 
> So maybe the right attitude is "hg2git should not be generating such
> broken commits"

I think this is true.

> (or "gitk should not barf on such broken commits" :) ),

And I think this is *also* true.

> 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?

I think git itself is quite robust in the face of duplicate parents, and it really is a gitk bug that it has problems with them. That said, I don't think we should *assume* they don't happen, and while we should consider it a bug in hg2git that they did, it is not a "serious" bug per se. It's only gitk that reacts this violently to it.

I guess we could prune duplicate parents even for commits that didn't get rewritten, but I don't see why we really should even have to. I think Paul already said that he should look into it:

			    "I see from the following messages that the
    bug turned out to be elsewhere in git, but it looks like gitk should 
    be more robust and do something sensible rather than just throwing a 
    Tcl error.  I'll look at it."

so I think we should fix gitk regardless, and then *maybe* also consider doing parent simplification universally.

			Linus