From: Marco Costalba Date: Sat, 09 Sep 2006 08:47:49 GMT Subject: Re: Change set based shallow clone Message-ID: In-Reply-To: On 9/9/06, Linus Torvalds wrote: > > > > In contrast, doing some of the same sorting that git-rev-list already does > in the consumer instead, is obviously duplicating the same basic notions, > but once you do it in the consumer, you can suddenly do things that simply > weren't possible in git-rev-list - do things incrementally, and then if > you notice half-way that you did something wrong, you can go back and fix > it up (which can be quite acceptable). That just isn't an option in a > linear environment like the git-rev-list output. > Perhaps is total idiocy but why do not implement the fix-up logic directly in git-rev-list? If the out of order revisions are a small amount of the total then could be possible to have something like git rev-list --topo-order --with-appended-fixups HEAD Where, while git-rev-list is working _whithout sorting the whole tree first_, when finds an out of order revision stores it in a fixup-list buffer and *at the end* of normal git-rev-lsit the buffer is flushed to receiver, so that the drawing logic does not change and the out of order revisions arrive at the end, already packed, sorted and prepared by git-rev-list. Instead of changing drwing logic is then enough to add a fixup routine that cycles through out of order commits and updates the graph. This also avoids recursive reordering where perhaps the same part of a graph should be redrawn more then one time due to differtent new parents to the same child arrives at different times. Marco