{"thread":{"id":"14556","subject":"What's cooking in git.git (2008-07 issue #9)","startedAt":"2008-07-21T05:31:02Z","lastAt":"2008-07-21T06:33:33Z","messageCount":2,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"84140","messageId":"7vtzejx0q1.fsf@gitster.siamese.dyndns.org","threadId":"14556","inReplyTo":null,"subject":"What's cooking in git.git (2008-07 issue #9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-21T05:31:02Z","receivedAt":"2008-07-21T05:31:02Z","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'.\n\nThe topics list the commits in reverse chronological order.  The topics\nmeant to be merged to the maintenance series have \"maint-\" in their names.\n\nDue to increased activity level from people including GSoC students, I\nexpect 'next' to stay somewhat more active than previous rounds during the\n1.6.0-rc cycle.  The request for people who usually follow 'next' is the\nsame as usual, though.  After -rc1 is tagged, please run 'master' for your\ndaily git use instead, in order to make sure 'master' does what it claims\nto do without regression.\n\nTentative schedule, my wishful thinking:\n\n - 1.6.0-rc0 (Jul 20)\n - 1.6.0-rc1 (Jul 23)\n - 1.6.0-rc2 (Jul 30)\n - 1.6.0-rc3 (Aug  6)\n - 1.6.0     (Aug 10)\n\n----------------------------------------------------------------\n[New Topics]\n\n* pb/sane-mv (Mon Jul 21 02:25:56 2008 +0200) 2 commits\n - git-mv: Keep moved index entries inact\n - git-mv: Remove dead code branch\n\nRunning \"git mv A B\" when you have local changes to A automatically staged\nit while moving it to B, which was a longstanding nonsense.  This attempts\nto fix it.  Pasky has other plans to build on a more solidified foundation\nto enhance the command to work with submodules better on top of this.\n\n----------------------------------------------------------------\n[Graduated to \"master\"]\n\n* ns/am-abort (Wed Jul 16 19:39:10 2008 +0900) 1 commit\n + git am --abort\n\nThis one is for Ted; builds on top of the recent \"am and rebase leaves\nORIG_HEAD just like reset, merge and pull does\" rather nicely.\n\n* jc/rerere-auto-more (Wed Jul 16 20:25:18 2008 -0700) 1 commit\n + rerere.autoupdate: change the message when autoupdate is in effect\n\nThis one is for Ingo.\n\nThis changes the message rerere issues after reusing previous conflict\nresolution from \"Resolved\" to \"Staged\" when autoupdate option is in\neffect.\n\nIt is envisioned that in practice, some auto resolutions are trickier and\niffier than others, and we would want to add a feature to mark individual\nresolutions as \"this is ok to autoupdate\" or \"do not autoupdate the result\nusing this resolution even when rerere.autoupdate is in effect\" in the\nfuture.  When that happens, these messages will make the distinction\nclearer.\n\n* ap/trackinfo (Wed Jul 16 15:19:27 2008 -0400) 1 commit\n + Reword \"your branch has diverged...\" lines to reduce line length\n\n* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits\n + Teach git-merge -X<option> again.\n + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next\n + builtin-merge.c: use parse_options_step() \"incremental parsing\"\n   machinery\n + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next\n\n* jc/merge-theirs (Fri Jul 18 02:43:00 2008 -0700) 6 commits\n - Document that merge strategies can now take their own options\n + Make \"subtree\" part more orthogonal to the rest of merge-\n   recursive.\n + Teach git-pull to pass -X<option> to git-merge\n + Teach git-merge to pass -X<option> to the backend strategy module\n + git-merge-recursive-{ours,theirs}\n + git-merge-file --ours, --theirs\n\nIt appears nobody wants \"theirs\" nor \"ours\", so I'll soon apply a\nwholesale revert for these series to 'next', and then these will be\ndropped when we rewind 'next' after 1.6.0 final.\n\nPlease make sure next time somebody asks \"ours/theirs\" merge on the list\nand #git s/he is quickly told that it was unanimously rejected so that\npeople do not have to waste time rehashing the topic ever again.\n\n----------------------------------------------------------------\n[Stalled/Needs more work]\n\n* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits\n - Documentation: Improve documentation for git-imap-send(1)\n - imap-send.c: more style fixes\n - imap-send.c: style fixes\n - git-imap-send: Support SSL\n - git-imap-send: Allow the program to be run from subdirectories of\n   a git tree\n\nI said: \"Some people seem to prefer having this feature available also\nwith gnutls.  If such a patch materializes soon, that would be good, but\notherwise I'll merge this as-is to 'next'.  Such an enhancement can be\ndone in-tree on top of this series.\"  Anybody?\n\n* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit\n . cherry: cache patch-ids to avoid repeating work\n\nThe discussion suggested that the value of having the cache itself is\niffy, but I should pick up the updated one and look at it.\n\n* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits\n . gitweb: use new Git::Repo API, and add optional caching\n . Add new Git::Repo API\n . gitweb: add test suite with Test::WWW::Mechanize::CGI\n\n* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits\n . Migrate git-am to use git-sequencer\n . Add git-sequencer test suite (t3350)\n . Add git-sequencer prototype documentation\n . Add git-sequencer shell prototype\n\nI haven't looked at the updated series yet.  I should, but nobody else\nseems to be looking at these patches, which is somewhat depressing but\nunderstandable.  Summer is slower ;-)\n\n* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit\n - [BROKEN wrt shallow clones] Ignore graft during object transfer\n\nCloning or fetching from a repository from grafts did not send objects\nthat are hidden by grafts, but the commits in the resulting repository do\nneed these to pass fsck.  This fixes object transfer to ignore grafts.\n\nAnother fix is needed to git-prune so that it ignores grafts but treats\ncommits that are mentioned in grafts as reachable.\n\n* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits\n - blame: show \"previous\" information in --porcelain/--incremental\n   format\n - git-blame: refactor code to emit \"porcelain format\" output\n\nThis is for peeling the line from the blamed version to see what's behind\nit, which may or may not help applications like gitweb.\n\n----------------------------------------------------------------\n[Dropped]\n\n* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits\n + Teach git-merge -X<option> again.\n + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next\n + builtin-merge.c: use parse_options_step() \"incremental parsing\"\n   machinery\n + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next\n\n* jc/merge-theirs (Fri Jul 18 02:43:00 2008 -0700) 6 commits\n - Document that merge strategies can now take their own options\n + Make \"subtree\" part more orthogonal to the rest of merge-\n   recursive.\n + Teach git-pull to pass -X<option> to git-merge\n + Teach git-merge to pass -X<option> to the backend strategy module\n + git-merge-recursive-{ours,theirs}\n + git-merge-file --ours, --theirs\n\nIt appears nobody wants \"theirs\" nor \"ours\", so I'll soon apply a\nwholesale revert for these series to 'next', and then these will be\ndropped when we rewind 'next' after 1.6.0 final.\n\nPlease make sure next time somebody asks \"ours/theirs\" merge on the list\nand #git s/he is quickly told that it was unanimously rejected so that\npeople do not have to waste time rehashing the topic ever again.\n\n----------------------------------------------------------------\n[On Hold]\n\n* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit\n + merge: remove deprecated summary and diffstat options and config\n   variables\n\nThis was previously in \"will be in master soon\" category, but it turns out\nthat the synonyms to the ones this one deletes are fairly new invention\nthat happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps\nin 1.7.0.\n\n* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits\n + Revert \"Make clients ask for \"git program\" over ssh and local\n   transport\"\n + Make clients ask for \"git program\" over ssh and local transport\n\nThis is the \"botched\" one.  Will be resurrected during 1.7.0 or 1.8.0\ntimeframe.\n\n* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit\n - diff: enable \"too large a rename\" warning when -M/-C is explicitly\n   asked for\n\nThis would be the right thing to do for command line use, but gitk will be\nhit due to tcl/tk's limitation, so I am holding this back for now.\n"},{"id":"84142","messageId":"7vy73vvj9e.fsf@gitster.siamese.dyndns.org","threadId":"14556","inReplyTo":"7vtzejx0q1.fsf@gitster.siamese.dyndns.org","subject":"What's _not_ cooking in git.git yet","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-21T06:33:33Z","receivedAt":"2008-07-21T06:33:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"There are a few topics that are still not ready but should be in the -rc1.\n\n * I want Pasky's \"saner git-mv\" to be in if possible, although I am\n   moderately pessimistic about the submodule work that comes on top of\n   it.\n\n * \"optimize ssh connection for throughput not for latency\" may be a\n   worthy goal, but I think the point Jeff raised about the shared\n   connection is a valid concern.  It might be better not to do anything\n   funky at the software level, but just add an entry in tips&tricks\n   section of gitwiki.\n\nOther than that, we should be focused more on fixes on regressions (if\nany), fixes in new features added in v1.6.0 cycle, than adding not-yet-in\nfeatures nor code clean-ups.\n\nI'll switch my production branch to 'master' tonight.  I expect active\ncontributors to do the same and keep it that way until 1.6.0 final.  Right\nnow, with 'merge -Xtheirs' removed, the difference between 'master' and\n'next' is extremely thin.\n\nThanks.\n"}]}