{"thread":{"id":"6174","subject":"What's cooking in git.git (topics)","startedAt":"2006-12-31T08:07:17Z","lastAt":"2007-01-01T21:18:29Z","messageCount":4,"participants":["Junio C Hamano","Juergen Ruehle","Johannes Schindelin","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30570","messageId":"7vhcvcfpze.fsf@assigned-by-dhcp.cox.net","threadId":"6174","inReplyTo":null,"subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-31T08:07:17Z","receivedAt":"2006-12-31T08:07:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* jc/send-pack-pipeline (Fri Dec 29 12:14:30 2006 -0800) 2 commits\n + Documentation: illustrate send-pack pipeline.\n + send-pack: fix pipeline.\n\nThere was a longstanding bug that was exposed only by accident\nwhen used with Shawn's sliding mmap changes (sp/mmap), and these\nare to fix it.  I'll merge this to 'master' before v1.5.0-rc1.\n\n* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits\n + Update packedGit config option documentation.\n + mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()\n + pack-objects: fix use of use_pack().\n + Fix random segfaults in pack-objects.\n + Cleanup read_cache_from error handling.\n + Replace mmap with xmmap, better handling MAP_FAILED.\n + Release pack windows before reporting out of memory.\n + Default core.packdGitWindowSize to 1 MiB if NO_MMAP.\n + Test suite for sliding window mmap implementation.\n + Create pack_report() as a debugging aid.\n + Support unmapping windows on 'temporary' packfiles.\n + Improve error message when packfile mmap fails.\n + Ensure core.packedGitWindowSize cannot be less than 2 pages.\n + Load core configuration in git-verify-pack.\n + Fully activate the sliding window pack access.\n + Unmap individual windows rather than entire files.\n + Document why header parsing won't exceed a window.\n + Loop over pack_windows when inflating/accessing data.\n + Replace use_packed_git with window cursors.\n + Refactor how we open pack files to prepare for multiple windows.\n + Create read_or_die utility routine.\n + Use off_t for index and pack file lengths.\n + Refactor packed_git to prepare for sliding mmap windows.\n + Introduce new config option for mmap limit.\n + Replace unpack_entry_gently with unpack_entry.\n\nThis is Shawn's sliding mmap series to allow smaller virtual\nmemory footprint to access larger packfiles.  I started using\nthis series in production tonight.  Although the size of the\nseries is somewhat intimidating, they are sane changes and I\nthink it may be worth considering for 'master'.  This does not\nchange the user experience majorly as has almost no UI elements,\nso it could go in either before or after v1.5.0.\n\n* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit\n + git-merge: preserve and merge local changes when doing fast\n   forward\n\nA few people wanted to have this in v1.5.0, but I am a bit\nreluctant to do so --- I think the behaviour of its failure mode\nis rather nasty, even though it tries to help the user by\ndropping the local diff in .git/LOCAL_DIFF file.\n\n* sp/merge (Sun Dec 31 00:02:13 2006 -0500) 6 commits\n - Refresh the index before starting merge-recursive.\n - Improve merge performance by avoiding in-index merges.\n - Avoid git-fetch in `git-pull .` when possible.\n + Use merge-recursive in git-am -3.\n + Allow merging bare trees in merge-recursive.\n + Move better_branch_name above get_ref in merge-recursive.\n\nI'm reasonably happy with the earlier three of this series but\nnot really about the latter, and I've already described why.\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit\n - git-explain\n* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit\n - gitweb: steal loadavg throttle from kernel.org\n* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit\n - blame: --show-stats for easier optimization work.\n* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit\n + git-diff/git-apply: make diff output a bit friendlier to GNU patch\n   (part 2)\n\nThese are not for 'master' for now.\n"},{"id":"30579","messageId":"17815.48485.178000.90522@lapjr.intranet.kiel.bmiag.de","threadId":"6174","inReplyTo":"7vhcvcfpze.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Juergen Ruehle","fromEmail":"j.ruehle@bmiag.de","sentAt":"2006-12-31T13:38:45Z","receivedAt":"2006-12-31T13:38:45Z","isPatch":false,"sender":{"key":"j.ruehle@bmiag.de","avatar":null},"body":"Junio C Hamano writes:\n > * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit\n >  + git-merge: preserve and merge local changes when doing fast\n >    forward\n > \n > A few people wanted to have this in v1.5.0, but I am a bit\n > reluctant to do so --- I think the behaviour of its failure mode\n > is rather nasty, even though it tries to help the user by\n > dropping the local diff in .git/LOCAL_DIFF file.\n\nIt happened to me (not really an experienced user) for the first time\non the last pull. Though unexpected it wasn't an unpleasant\nexperience. The failure mode doesn't feel smooth, but after thinking\nabout possible improvements I couldn't come up with anything better.\nIt already states explicitly what it's doing including telling the\nuser about LOCAL_DIFF. The only thing I wasn't sure about was how to\nget rid of the unmerged index entries after I fixed the conflicts\nwithout adding the local change to the index. In the end I did an\nupdate-index/reset combination, but perhaps repeating the list of\nfiles with conflicting local changes after the merge and cleaning the\nindex instead of leaving unmerged entries in the index would be\nbetter.\n\nI think (because of LOCAL_DIFF) it is safe to have this in 1.5 even in\nits current incarnation.\n"},{"id":"30580","messageId":"Pine.LNX.4.63.0612311602160.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6174","inReplyTo":"7vhcvcfpze.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-31T15:04:48Z","receivedAt":"2006-12-31T15:04:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 31 Dec 2006, Junio C Hamano wrote:\n\n> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit\n>  + git-merge: preserve and merge local changes when doing fast\n>    forward\n> \n> A few people wanted to have this in v1.5.0, but I am a bit reluctant to \n> do so --- I think the behaviour of its failure mode is rather nasty, \n> even though it tries to help the user by dropping the local diff in \n> .git/LOCAL_DIFF file.\n\nI am not urging the inclusion in 1.5.0, but how about storing not the \ndiff, but the _state_ in .git/UNCOMMITTED_TREE? This would work with all \nthe git tools without any problem, and git-gc would eventually clean up \nolder intermediate stages.\n\nCiao,\nDscho\n"},{"id":"30626","messageId":"20070101211829.GC26821@spearce.org","threadId":"6174","inReplyTo":"7vhcvcfpze.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-01T21:18:29Z","receivedAt":"2007-01-01T21:18:29Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> * sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits\n> \n> This is Shawn's sliding mmap series to allow smaller virtual\n> memory footprint to access larger packfiles.  I started using\n> this series in production tonight.  Although the size of the\n> series is somewhat intimidating, they are sane changes and I\n> think it may be worth considering for 'master'.  This does not\n> change the user experience majorly as has almost no UI elements,\n> so it could go in either before or after v1.5.0.\n\nI know your testing is saying this series may be slightly faster than\nthe prior code in 'master', and at least on Linux can be so without\nusing a lot of virtual address space as mmap() is so fast there.\n(Nice job kernel people!)  Anyway, I haven't done any performance\ntesting on this myself.  It would be nice to know more about how\nit behaves.\n \n> * sp/merge (Sun Dec 31 00:02:13 2006 -0500) 6 commits\n>  - Refresh the index before starting merge-recursive.\n>  - Improve merge performance by avoiding in-index merges.\n>  - Avoid git-fetch in `git-pull .` when possible.\n>  + Use merge-recursive in git-am -3.\n>  + Allow merging bare trees in merge-recursive.\n>  + Move better_branch_name above get_ref in merge-recursive.\n> \n> I'm reasonably happy with the earlier three of this series but\n> not really about the latter, and I've already described why.\n\nI know you've stated a number of good reasons against \"Avoid\ngit-fetch in `git-pull .` when possible.\".  One way I've thought\nof trying to resolve that would be to verify the arguments to\n`git pull .` are refs only (and not SHA1 expressions) which makes\nthe behavior the same as `git pull .` and *might* still save time,\nas the fetch can still get bypassed.\n\nThe only objection I know of to \"Improve merge performance by\navoiding in-index merges.\" was that it needs more testing to ensure\nits doing the same thing as before, which basically means we hold it\nout until post v1.5.0.  Since it is only a performance improvement\nI think that's reasonable.\n\n-- \nShawn.\n"}]}