Re: What's cooking in git.git (topics)

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jan 1, 2007, 21:18 UTC
Message-ID: <20070101211829.GC26821@spearce.org>
In-Reply-To: <7vhcvcfpze.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 9 quoted lines

> * sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
> 
> This is Shawn's sliding mmap series to allow smaller virtual
> memory footprint to access larger packfiles.  I started using
> this series in production tonight.  Although the size of the
> series is somewhat intimidating, they are sane changes and I
> think it may be worth considering for 'master'.  This does not
> change the user experience majorly as has almost no UI elements,
> so it could go in either before or after v1.5.0.

I know your testing is saying this series may be slightly faster than
the prior code in 'master', and at least on Linux can be so without
using a lot of virtual address space as mmap() is so fast there.
(Nice job kernel people!)  Anyway, I haven't done any performance
testing on this myself.  It would be nice to know more about how
it behaves.

Show 10 quoted lines

> * sp/merge (Sun Dec 31 00:02:13 2006 -0500) 6 commits
>  - Refresh the index before starting merge-recursive.
>  - Improve merge performance by avoiding in-index merges.
>  - Avoid git-fetch in `git-pull .` when possible.
>  + Use merge-recursive in git-am -3.
>  + Allow merging bare trees in merge-recursive.
>  + Move better_branch_name above get_ref in merge-recursive.
> 
> I'm reasonably happy with the earlier three of this series but
> not really about the latter, and I've already described why.

I know you've stated a number of good reasons against "Avoid git-fetch in `git-pull .` when possible.". One way I've thought of trying to resolve that would be to verify the arguments to `git pull .` are refs only (and not SHA1 expressions) which makes the behavior the same as `git pull .` and *might* still save time, as the fetch can still get bypassed.

The only objection I know of to "Improve merge performance by avoiding in-index merges." was that it needs more testing to ensure its doing the same thing as before, which basically means we hold it out until post v1.5.0. Since it is only a performance improvement I think that's reasonable.

-- 
Shawn.