Re: fsck --full is Ok, but clones are not, "missing commits"?!

Johannes Sixt wrote:

Brian Foster schrieb:

quoted

 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-

Brian Foster schrieb:

Johannes Sixt wrote:

quoted

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.

For me, the unusable scrollbar alone would be reason enough to truncate
the history. Once it is truncated, performance is no longer an issue
(whether or not it was an issue in the first place).

 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?

Well, I have gitk running all the time. So, yes, it is "important." But I
 run it basically as 'gitk --all --not origin' and press F5 frequently.
With this set of arguments the scrollbar remains usable, and performance
is not an issue, even on Windows.

-- Hannes