What's cooking in git.git (topics)

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.

* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
 + Update packedGit config option documentation.
 + mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
 + pack-objects: fix use of use_pack().
 + Fix random segfaults in pack-objects.
 + Cleanup read_cache_from error handling.
 + Replace mmap with xmmap, better handling MAP_FAILED.
 + Release pack windows before reporting out of memory.
 + Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
 + Test suite for sliding window mmap implementation.
 + Create pack_report() as a debugging aid.
 + Support unmapping windows on 'temporary' packfiles.
 + Improve error message when packfile mmap fails.
 + Ensure core.packedGitWindowSize cannot be less than 2 pages.
 + Load core configuration in git-verify-pack.
 + Fully activate the sliding window pack access.
 + Unmap individual windows rather than entire files.
 + Document why header parsing won't exceed a window.
 + Loop over pack_windows when inflating/accessing data.
 + Replace use_packed_git with window cursors.
 + Refactor how we open pack files to prepare for multiple windows.
 + Create read_or_die utility routine.
 + Use off_t for index and pack file lengths.
 + Refactor packed_git to prepare for sliding mmap windows.
 + Introduce new config option for mmap limit.
 + Replace unpack_entry_gently with unpack_entry.

This is what I was looking at on Cygwin on my wife's box today
(I do not have an easy access to Windows boxes otherwise so my
Cygwin testing is limited to only weekends when I am at home).

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

Johannes's suggestion to record a tree object instead of
LOCAL_DIFF is roger but not wilco yet --- I haven't thought
through the issue to see an improvement in the suggestion.  We
will be clobbering both index and the working tree, and I think
"diff --binary HEAD" and "write-tree" record the equivalent
amount of information given a HEAD for recovery.

* sp/merge (Sun Dec 31 00:02:13 2006 -0500) 3 commits
 - Refresh the index before starting merge-recursive.
 - Improve merge performance by avoiding in-index merges.
 - Avoid git-fetch in `git-pull .` when possible.

Three patches in the earlier part of this series have graduated
to 'master' as I think they are useful.

* 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
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

These are on hold.

Hi,

On Mon, 1 Jan 2007, Junio C Hamano wrote:

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

Johannes's suggestion to record a tree object instead of LOCAL_DIFF is 
roger but not wilco yet --- I haven't thought through the issue to see 
an improvement in the suggestion.  We will be clobbering both index and 
the working tree, and I think "diff --binary HEAD" and "write-tree" 
record the equivalent amount of information given a HEAD for recovery.

For recovery, yes. The difference comes in

- that you can use the familiar git operations to recover (git read-tree 
  PRE_MERGE_TREE), and
- that you can do other git operations on the tree, but not on the diff.

Hth,
Dscho

On 1/2/07, Junio C Hamano [off-list ref] wrote:

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.

* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits

Running this and the merge-recursive speedup I sent today locally.
sp/mmap needs relatively recent cygwin library (otherwise pread
is broken). No other ill effects noticed. Perfomance is bearable.

Alex Riesen [off-list ref] wrote:

On 1/2/07, Junio C Hamano [off-list ref] wrote:

quoted

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.

* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits

Running this and the merge-recursive speedup I sent today locally.
sp/mmap needs relatively recent cygwin library (otherwise pread
is broken). No other ill effects noticed. Perfomance is bearable.

The default on Cygwin is now NO_MMAP.  I've disabled that default
in my own Cygwin environment and continue to use mmap() rather than
pread(), but I'm also running my sp/mmap change there.  I haven't
noticed a performance difference, but I also haven't tested for one.
IOW if there is a difference its close enough to noise to not be
visible to me as a user.

-- 
Shawn.

On 1/5/07, Shawn O. Pearce [off-list ref] wrote:

quoted

quoted

* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits

Running this and the merge-recursive speedup I sent today locally.
sp/mmap needs relatively recent cygwin library (otherwise pread
is broken). No other ill effects noticed. Perfomance is bearable.

The default on Cygwin is now NO_MMAP.  I've disabled that default

I left it at NO_MMAP: wanted to see how bad pread performs.
No worse than mmap, as it seems.

in my own Cygwin environment and continue to use mmap() rather than
pread(), but I'm also running my sp/mmap change there.  I haven't
noticed a performance difference, but I also haven't tested for one.
IOW if there is a difference its close enough to noise to not be
visible to me as a user.

Confirm that.