{"thread":{"id":"6111","subject":"What's cooking in git.git (topics)","startedAt":"2006-12-26T03:25:44Z","lastAt":"2006-12-26T19:52:56Z","messageCount":5,"participants":["Junio C Hamano","Shawn Pearce","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30289","messageId":"7vmz5bfidj.fsf@assigned-by-dhcp.cox.net","threadId":"6111","inReplyTo":null,"subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-26T03:25:44Z","receivedAt":"2006-12-26T03:25:44Z","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\n* jc/fsck-reflog (Fri Dec 22 23:42:30 2006 -0800) 9 commits\n + reflog expire: do not punt on tags that point at non commits.\n + reflog expire: prune commits that are not incomplete\n + Don't crash during repack of a reflog with pruned commits.\n + git reflog expire\n + Move in_merge_bases() to commit.c\n + reflog: fix warning message.\n + Teach git-repack to preserve objects referred to by reflog\n   entries.\n + Protect commits recorded in reflog from pruning.\n + add for_each_reflog_ent() iterator\n\nI'd like to push this out before we go -rc1, since the reflogs\nare now enabled by default, and otherwise would grow unbounded.\n\n\n* jc/utf8 (Mon Dec 25 11:48:35 2006 -0800) 3 commits\n - Teach log family --encoding\n - i18n.logToUTF8: convert commit log message to UTF-8\n - Move encoding conversion routine out of mailinfo to utf8.c\n\nThis allows repositories to have commit messages in \"wrong\"\nencodings, and converts them to UTF-8 upon \"git log\" output.  I\nthink it is much nicer solution than insisting the commit log\nmessage to always be in UTF-8, especially with automated\nconversion when making a commit.  If the conversion is botched\n(or involves non-reversible conversion) at commit time, the\ninformation is lost forever, but even if the conversion at the\noutput time fails or loses information, the log message can be\nrecovered in the original encoding, and conversion can later be\nfixed/improved.\n\nThis is not a must-have for v1.5.0, but I feel it would be\nbetter to push it out as it can introduce slight backward\nincompatibility to people's scripts, if they are expecting to\nget messages in original encodings.  If we are going to break\nthem, we would be better off breaking them at a major revision\nboundary than later.\n\n\n* sp/mmap (Sun Dec 24 00:47:23 2006 -0500) 20 commits\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\nI wanted to have this in 'next' but it appears that this makes\ngit-push with a non-trivial amount of data to fail.  v1.5.0 does\nnot have to wait for this because this should not change any UI.\n\n\nAll the rest are post v1.5.0; some of them will never be merged.\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* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits\n + fetch-pack: Do not fetch tags for shallow clones.\n + get_shallow_commits: Avoid memory leak if a commit has been\n   reached already.\n + git-fetch: Reset shallow_depth before auto-following tags.\n + upload-pack: Check for NOT_SHALLOW flag before sending a shallow\n   to the client.\n + fetch-pack: Properly remove the shallow file when it becomes\n   empty.\n + shallow clone: unparse and reparse an unshallowed commit\n + Why didn't we mark want_obj as ~UNINTERESTING in the old code?\n + Why does it mean we do not have to register shallow if we have\n   one?\n + We should make sure that the protocol is still extensible.\n + add tests for shallow stuff\n + Shallow clone: do not ignore shallowness when following tags\n + allow deepening of a shallow repository\n + allow cloning a repository \"shallowly\"\n + support fetching into a shallow repository\n + upload-pack: no longer call rev-list\n\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\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* jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit\n - gitweb: Add some mod_perl specific support\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"},{"id":"30290","messageId":"20061226042110.GA28084@spearce.org","threadId":"6111","inReplyTo":"7vmz5bfidj.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-26T04:21:10Z","receivedAt":"2006-12-26T04:21:10Z","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 (Sun Dec 24 00:47:23 2006 -0500) 20 commits\n>\n> I wanted to have this in 'next' but it appears that this makes\n> git-push with a non-trivial amount of data to fail.  v1.5.0 does\n> not have to wait for this because this should not change any UI.\n\nReally?  Not good.  Do you have some sort of test case that has\ncaused this?  I'll try to reproduce it here on my own.\n\n-- \nShawn.\n"},{"id":"30293","messageId":"20061226045933.GB28084@spearce.org","threadId":"6111","inReplyTo":"20061226042110.GA28084@spearce.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-26T04:59:33Z","receivedAt":"2006-12-26T04:59:33Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Shawn Pearce <spearce@spearce.org> wrote:\n> Junio C Hamano <junkio@cox.net> wrote:\n> > * sp/mmap (Sun Dec 24 00:47:23 2006 -0500) 20 commits\n> >\n> > I wanted to have this in 'next' but it appears that this makes\n> > git-push with a non-trivial amount of data to fail.  v1.5.0 does\n> > not have to wait for this because this should not change any UI.\n> \n> Really?  Not good.  Do you have some sort of test case that has\n> caused this?  I'll try to reproduce it here on my own.\n\nI've pushed all of git.git into an empty repository, and then\npushed another 1639 objects on top of that, without any errors.\nSo I can't seem to reproduce the problem here in my Mac OS X system.\n\nBTW, I do agree that sp/mmap should not be in v1.5.0.\n\n-- \nShawn.\n"},{"id":"30298","messageId":"emr0bt$hcb$2@sea.gmane.org","threadId":"6111","inReplyTo":"7vmz5bfidj.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-26T11:20:07Z","receivedAt":"2006-12-26T11:20:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Here are the topics that have been cooking.  Commits prefixed\n> with '-' are only in 'pu' while commits prefixed with '+' are\n> in 'next'.  The topics list the commits in reverse chronological\n> order.\n> \n> \n> * jc/fsck-reflog (Fri Dec 22 23:42:30 2006 -0800) 9 commits\n>  + reflog expire: do not punt on tags that point at non commits.\n>  + reflog expire: prune commits that are not incomplete\n>  + Don't crash during repack of a reflog with pruned commits.\n>  + git reflog expire\n>  + Move in_merge_bases() to commit.c\n>  + reflog: fix warning message.\n>  + Teach git-repack to preserve objects referred to by reflog\n>    entries.\n>  + Protect commits recorded in reflog from pruning.\n>  + add for_each_reflog_ent() iterator\n> \n> I'd like to push this out before we go -rc1, since the reflogs\n> are now enabled by default, and otherwise would grow unbounded.\n\nI'd still like the preserving reflogged data during pruning and\nrepacking to be optional (default to on). But failing that I'd\nlike to have option to \"reflog expire\" to remove only specific\n(pattern match, prefix match?) entries, for example to remove\nall the \"commit --amend\" and StGIT work, but leaving rebases,\nresets, merges and other stuff.\n\n> * jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit\n>  - gitweb: Add some mod_perl specific support\n\nI'm about to send improved series of patches, few first ready to\nbe applied, the rest for review.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30312","messageId":"7vwt4ecu3r.fsf@assigned-by-dhcp.cox.net","threadId":"6111","inReplyTo":"emr0bt$hcb$2@sea.gmane.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-26T19:52:56Z","receivedAt":"2006-12-26T19:52:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> I'd still like the preserving reflogged data during pruning and\n> repacking to be optional (default to on).\n\nWhat does that really _mean_?\n\nSome time after reflog was introduced, you started talking about\nit on #git channel saying \"you could refer to master@{yesterday}\nto get it back, but only unless you pruned\".\n\nI think that behaviour was a bug, which was there only because\nreflog was bolted onto the plumbing as an afterthought.  If the\ndata reflog keeps is integral part of git (and in v1.5.0 we are\nmaking it so by turning it on by default), you should not have\nto say \"but only unless\" part, which indicates loss of useful\ninformation.\n\nSo you either keep objects that reflog entries need, or you\ndiscard reflog entries that point at them when you discard\ncertain objects you do not need anymore.  Removing objects\nwithout removing reflog entries that become stale because of\nmissing objects takes us back to the \"bolted on, not really\nintegrated\" situation.  It makes reflog \"sometimes work but only\nsometimes\", and most likely it does not work when the user most\nwants it to.\n\nWith the current code in 'next', you can discard unwanted reflog\nentries using \"reflog expire\", and then do prune/repack, and can\nbe assured that the objects that remaining reflog entries want\nare still there (modulo bugs -- at least that is the intent).\nYou could update prune/repack so that they do not look at reflog\ndata, and have them also remove reflog entries that have become\nstale after they do their primary things (either pruning or\nrepacking), as part of the same invocation.  I will not code\nthat for you because I do not think it is an improvement over\nwhat we have now (for one thing, you cannot prune selectively,\nas I already said).\n\n> But failing that I'd\n> like to have option to \"reflog expire\" to remove only specific\n> (pattern match, prefix match?) entries, for example to remove\n> all the \"commit --amend\" and StGIT work, but leaving rebases,\n> resets, merges and other stuff.\n\nI would say \"Patches welcome\"; this is not from my sarcastic\nside but because I suspect there might be a remote chance that\nit might turn out to be useful in some situation.  It is just\nthat my suspicion is not strong enough to tempt me to do so\nmyself, because I think that even with such an elaborate\nselection mechanism in place, what the users would do in\npractice would boil down to what --expire-unreachable does.\n"}]}