Re: Change set based shallow clone

From: linux@horizon.com <linux@horizon.com>
Date: Sep 11, 2006, 12:39 UTC
Message-ID: <20060911123937.6521.qmail@science.horizon.com>
In-Reply-To: <17669.13028.198886.947400@cargo.ozlabs.ibm.com>

Show 5 quoted lines

>> I'm trying to figure out the gitk code, but I'm not fluent in tcl, and
>> it has 39 non-boilerplate comment lines in 229 functions and 6308 lines
>> of source, so it requires fairly intensive grokking.
>
> Sorry :)

I was more making excuses for my failure to understand its properties. Still, if you get the chance, a couple of paragraphs of comments on the primary data structures would be an immense help.

Anyway, thanks for the summary.

>> For example, is fixing a small number of out-of-place commits practical,
>> or is it better to purge and restart?  The former avoids deleting
>> already-existing objects, while the latter avoids moving them.

Show 9 quoted lines

> For gitk, I'm thinking of a reorder buffer of say 10 entries at the
> front end to cope with minor misorderings; then if misordering occurs
> that is outside the scope of the reorder buffer to fix, freeze the
> layout algorithms at that point, read in the rest of the commits and
> reorder as necessary, then at the end restart the layout algorithm
> from scratch, probably with a popup to inform the user what happened.
> If the user could set the size of the reorder buffer then they could
> avoid having that happen in future, at the cost of it taking longer to
> show the first screenful of commits.

My thoughts were that anything you could do, git-rev-list could do better, including the re-order buffer, so don't even bother. (For example, I was thinking of a time- or depth-based one rather than a count-based one.)

So I read your suggestion as a "purge and restart" preference, with git-rev-list keeping a cache of problems encountered so that on most runs, it doesn't have to do it. Putting that logic in git-rev-list means that you don't have to detect ordering problems or do any sorting, just handle an "oops!" line in the output.

Basically, given the example graph (with letters indicating timestamps)

...G--D--C--B---A
          \    /
           F--E

You'd get something like A B E B C C D D G E F *** ERROR - restarting - please wait A B E B C E F F C C D D G G ...