Re: Change set based shallow clone

From: Paul Mackerras <paulus@samba.org>
Date: Sep 9, 2006, 01:05 UTC
Message-ID: <17666.4936.894588.825011@cargo.ozlabs.ibm.com>
In-Reply-To: <Pine.LNX.4.64.0609081600530.27779@g5.osdl.org>

Linus Torvalds writes:

Show 13 quoted lines

> [ One way to do it might be: the normal ordering of revisions without 
>   "--topo-order) is "_close_ to topological", and gitk could just decide 
>   to re-compute the whole graph whenever it gets a commit that has a 
>   parent that it has already graphed. Done right, it would probably almost 
>   never actually generate re-computed graphs (if you only actually 
>   generate the graph when the user scrolls down to it).
> 
>   Getting rid of the --topo-order requirement would speed up gitk 
>   absolutely immensely, especially for unpacked cold-cache archives. So it 
>   would probably be a good thing to do, regardless of any shallow clone 
>   issues ]
> 
> Hmm?

I recently added code to gitk to add extra commits after the graph has been laid out, provided that the extra commits have one parent and no children. If I generalized that to handle arbitrary numbers of parents and children, it might go close to what you're suggesting.

It might get nasty if we have laid out A and then later B, and then C comes along and turns out to be a child of A but a parent of B, meaning that both B and C have to be put above A.

Another thing I have been thinking of is that gitk probably should impose a time limit of say 3 months by default, unless the user specifies some other ending condition (such as commitid.., ^commitid or --since=something-else). Together with a menu to select the time limit, I think that would be quite usable and would make gitk start up *much* faster.

Paul.