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. - 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
