Show 20 quoted lines
> 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-