Re: git and larger trees, not so fast?
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Aug 10, 2007, 01:42 UTC
- Message-ID
- <Pine.LNX.4.64.0708092131030.10711@iabervon.org>
- In-Reply-To
- <7vtzr8wemb.fsf@assigned-by-dhcp.cox.net>
On Thu, 9 Aug 2007, Junio C Hamano wrote:
Show 23 quoted lines
> Linus Torvalds <torvalds@linux-foundation.org> writes: > > > On Thu, 9 Aug 2007, Linus Torvalds wrote: > >> > >> So "builtin-read-tree.c" (or rather unpack-trees.c) would need the same > >> kind of logic. > > > > The path seems to be: > > > > cmd_read_tree -> > > unpack_trees -> > > unpack_trees_rec -> > > [ recursive .. unpack_trees_rec ] -> > > oneway_merge -> > > keep_entry -> > > add_index_entry() > > > > and here again we end up having the same insertion sort issue. > > Quite honestly, I was this (shows the "thumb and index finger > almost touching" gesture) close to declare that unpack-trees is > unsalvageable, and was planning to redo the one-tree (and > perhaps two-tree) read-tree without using that mess after 1.5.3.
Yeah, that's probably the right thing to do; I wrote it with the idea that we'd be doing many-parent merges with it, but merge-recursive turned out to be a better idea, so I designed it to be comprehensible for a complicated case we never actually do.
-Daniel *This .sig left intentionally blank*