Johannes Sixt wrote: > Brian Foster schrieb: > > What I don't know is the root-cause, that is, WHY > > this was done. [ ... ] there is some anecdotal > > evidence it was some sort of a CPU-cycles issue, > > albeit just what the performance hit was is unknown. > > How about this theory: > > What happens if you fire up gitk as simple as > > $ gitk > > in the history if no grafts are present? Some months ago this took ages to > complete, and even today you get a *huge* list of commits in a *short* > window; hence, the scrollbar thumb is tiny, and if you succeed to get hold > of it without a magnifying glass, it scrolls way more than a page of > commits if you move it by only one pixel. > > No wonder that $user wants to have a shorter history. So $user, being > smart, truncates the history at a suitable point with a graft. Hannes, Unfortunately, I cannot fire up `gitk' in the exact same configuration anymore (that server machine is now being used for other purposes, albeit I'm supposed to get the hard disc). The git on the now-vanished server was v1.5.3, but that's probably not relevant, since the repository must have been created with a much older git (it goes back multiple years). All the (now-)installed gits I've seen are 1.5.<something>. I do not see any noticeable performance issue with 1.5.2.5 (nor with 1.5.5)? The scrollbar is, as you say, unusable. But how important is `gitk'? Is it something that'd be used frequently enough for the formerly-poor performance to be such an issue that creating and maintaining such a "truncated" repository is worthwhile? It's an interesting and plausible hypothesis, but (in the absence of any actual evidence) I'd be more inclined to buy it if there was some frequent/critical operation where poor performance clearly matters. cheers! -blf- -- 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
