Re: What to expect after 0.99.8

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 3, 2005, 19:43 UTC
Message-ID: <Pine.LNX.4.63.0510031522590.23242@iabervon.org>
In-Reply-To: <7v7jcvxxrl.fsf@assigned-by-dhcp.cox.net>

On Sun, 2 Oct 2005, Junio C Hamano wrote:

Show 7 quoted lines

> What to expect after 0.99.8
> ===========================
> 
> This is written in a form of to-do list for me, so if I say
> "accept patch", it means I do not currently plan to do that
> myself.  People interested in seeing it materialize please take
> a hint.

Are these all before 1.0, or are some of them supposed to happen eventually but later?

Show 6 quoted lines

> Technical (heavier)
> -------------------
> 
> * Libification.  There are many places "run once" mentality is
>   ingrained in the management of basic data structures, which
>   need to be fixed.

I think this should be a post-1.0 thing; I think after 1.0, we should rearrange a lot of the code to make more sense from a programmer perspective.

> * 'git split-projects'?  This requires updated 'git-rev-list' to
>   skip irrelevant commits.
>   Message-ID: <Pine.LNX.4.63.0509221617300.23242@iabervon.org>

I thought about this some more, and realized that the operation to get additions to the gitk history out of a git repository is going to be slow, because you don't know the correct hashes for parents until you go all the way back. Still worth doing, but less exciting than I'd hoped.

> * Look at libified GNU diff CVS seems to use, or libxdiff.

I've almost got a suffix-tree-based diff that works reasonably well, that's built as a library, and outputs unified diff. I need to merge it with git, hook up input from trees and blobs, and test it on a wider set of data.

I'd also like to add:

 * Accept patches to fetch multiple objects by HTTP in parallel.

I think this may be necessary to get good performance without rsync for repositories hosted without specific git support.

	-Daniel
*This .sig left intentionally blank*