Re: git and larger trees, not so fast?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 9 Aug 2007, Junio C Hamano wrote:

> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux