What's cooking in git.git (topics)

Again, 'next' is getting quite lightweight compared to 'master'. Good time to do "war on whitespace" Marco suggested myself.

'pu' has Shawn's 'pu' from git-gui, to help people experiment with the proposed blame viewer improvements more easily. I personally like it quite a bit.

----------------------------------------------------------------

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' while commits prefixed with '+' are in 'next'. The topics list the commits in reverse chronological order.

* lh/submodules (Sat Jun 2 03:27:42 2007 +0200) 2 commits
 + Add basic test-script for git-submodule
 + Add git-submodule command

I find this a 'master' material already.  Will merge soon.

* gb/idx (Fri Jun 1 15:18:05 2007 -0400) 1 commit
 + Unify write_index_file functions

Should graduate to 'master' by mid next week.

* pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits
 + Remove git-applypatch
 + git-applymbox: Remove command

Will push out to 'master' soon to see if anybody screams.

* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
 - Enhance unpack-objects for live repo and large objects

I saw nobody other than Dana jump up and down and say we must have this, so I still parked this in 'pu' without merging it to 'next'. Maybe a time for a quick poll?

* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
 - blame: show log as it goes
 - git-blame: optimize get_origin() from linear search to hash-
   lookup.
 - git-blame: pass "struct scoreboard *" pointers around.
 - blame: lift structure definitions up

* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel

Backburnered. Further work on the latter, or something like that, or something based on (disused) git-merge-tree, is needed to exonerate Linus from having lied in the following part of his talk (there is a transcript at http://git.or.cz/gitwiki of his talk by the way):

    The source code may sometimes look complicated because we
    are very performance centric, I am.  I really care, and
    sometimes to make things go really fast, you have to use
    more complicated algorithms than just checking one file at a
    time.  When you are doing 22,000 file merges, you do not
    want to check one file at a time, you want to check the
    whole tree in one go and say, "Ah they are the same, I do
    not have to do anything".

as we _DO_ currently merge one path at a time.

You _could_ interpret "merge" in his message as applying millions of patches from Andrew, in which case it is true --- the cache-tree optimization in the index does help us skipping the unchanged tree recomputation. But that does not apply to a true merge, even when it is a trivial tree-level merge.