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