{"thread":{"id":"21584","subject":"excerpts from tomorrow's \"What's cooking\" draft","startedAt":"2009-11-11T09:34:07Z","lastAt":"2009-11-18T00:59:23Z","messageCount":36,"participants":["Junio C Hamano","Ben Walton","Johan Herland","Sverre Rabbelier","Nicolas Sebrecht","Daniel Barkalow","Jakub Narebski","Nicolas Pitre","Petr Baudis","Jonathan Nieder","Stephen Boyd","SZEDER Gábor","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"127344","messageId":"7vbpj9s8vk.fsf@alter.siamese.dyndns.org","threadId":"21584","inReplyTo":null,"subject":"excerpts from tomorrow's \"What's cooking\" draft","fromName":"Junio C Hamano","fromEmail":"junio@pobox.com","sentAt":"2009-11-11T09:34:07Z","receivedAt":"2009-11-11T09:34:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I'll do the full-list at the end of my git Wednesday, but here are the\ncurrent highlights I am sending out to hear opinions from people.\n\nPlease note that I haven't caught up with the patches from past 12 hours\nor so.\n\n----------------------------------------------------------------\n\n[New Topics]\n\n* jn/help-everywhere (2009-11-09) 21 commits\n - diff --no-index: make the usage string less scary\n - ...\n - Show usage string for 'git grep -h'\n (this branch uses jn/maint-http-fetch-mingw and jn/remove-fetch--tool.)\n\nThere were unrelated but still worthy fixes, so I reordered some of them;\nalso the \"usage()\" change is different from the one that was posted (see\nmy comment in $gmane/132592).\n\n* jn/maint-http-fetch-mingw (2009-11-09) 1 commit.\n - http-fetch: add missing initialization of argv0_path\n (this branch is used by jn/help-everywhere.)\n\n* jn/remove-fetch--tool (2009-11-09) 1 commit\n - Retire fetch--tool helper to contrib/examples\n (this branch is used by jn/help-everywhere.)\n\nThese two were originally part of the \"help-everywhere\" topic but\nthey can stand on their own.\n\n* jc/log-stdin (2009-11-03) 1 commit\n - Teach --stdin option to \"log\" family\n\nThis is not signed-off (see $gmane/131971 for list of things you can do to\nhelp advancing this topic).\n\n--------------------------------------------------\n[Stalled]\n\n* sc/protocol-doc (2009-10-29) 1 commit\n - Update packfile transfer protocol documentation\n\n* jl/submodule-add-noname (2009-09-22) 1 commit.\n - git submodule add: make the parameter optional\n\nDscho started an interesting discussion regarding the larger workflow in\nwhich the \"submodule add\" is used. I think the patch itself makes sense\nbut at the same time it probably makes sense to also take the and\ninfer the as Dscho suggested, probably in \"git submodule\nadd\", not in \"git add\" proper, at least initially.\n\nAny objections against merging this to 'next'?\n\n* jc/fix-tree-walk (2009-10-22) 11 commits.\n (merged to 'next' on 2009-10-22 at 10c0c8f)\n + Revert failed attempt since 353c5ee\n + read-tree --debug-unpack\n (merged to 'next' on 2009-10-11 at 0b058e2)\n + ...\n + diff-lib.c: fix misleading comments on oneway_diff()\n\nThis has some stupid bugs and temporarily reverted from 'next' until I can\nfix it, but the \"temporarily\" turned out to be very loooong. Sigh...\n\n* jh/notes (2009-10-09) 22 commits.\n - fast-import: Proper notes tree manipulation using the notes API\n - ...\n - Notes API: get_commit_notes() -> format_note() + remove the commit restriction\n (merged to 'next' on 2009-11-01 at 948327a)\n + Add selftests verifying concatenation of multiple notes for the same commit\n + ...\n + Introduce commit notes\n\nI somehow thought that the later API part was waiting for updates but\nnothing seems to be happening.\n\n* jn/gitweb-blame (2009-09-01) 5 commits.\n - gitweb: Minify gitweb.js if JSMIN is defined\n - gitweb: Create links leading to 'blame_incremental' using JavaScript\n (merged to 'next' on 2009-10-11 at 73c4a83)\n + gitweb: Colorize 'blame_incremental' view during processing\n + ...\n\nAjax-y blame. Any progress or RFH?\n\n* sr/gfi-options (2009-09-06) 6 commits.\n - fast-import: test the new option command\n - ...\n - fast-import: put option parsing code in separate functions\n\nIt seemed to be moving again soon, but nothing has happened yet...\n\n* je/send-email-no-subject (2009-08-05) 1 commit.\n (merged to 'next' on 2009-10-11 at 1b99c56)\n + send-email: confirm on empty mail subjects\n\nThe existing tests cover the positive case (i.e. as long as the user says\n\"yes\" to the \"do you really want to send this message that lacks subject\",\nthe message is sent) of this feature, but the feature itself needs its own\ntest to verify the negative case (i.e. does it correctly stop if the user\nsays \"no\"?)\n\n--------------------------------------------------\n[Cooking]\n\n* bw/autoconf-more (2009-11-04) 2 commits\n - configure: add settings for gitconfig, editor and pager\n - configure: add macro to set arbitrary make variables\n\nLooked sensible. Any comments?\n\n* bg/format-patch-doc-update (2009-11-07) 4 commits\n - format-patch: Add \"--no-stat\" as a synonym for \"-p\"\n - format-patch documentation: Fix formatting\n - format-patch documentation: Remove diff options that are not useful\n - format-patch: Always generate a patch\n\nLooked sensible, even though this may want to wait for 1.7.0. We'll see\nwhen we merge this to 'next'.\n\n* rj/maint-simplify-cygwin-makefile (2009-10-27) 1 commit.\n - Makefile: merge two Cygwin configuration sections into one\n (this branch is used by rj/cygwin-msvc.)\n\nThis is one of the most obviously correct bit from \"Compiling on Cygwin\nusing MSVC fails\" topic.\n\n* rj/cygwin-msvc (2009-11-09) 3 commits.\n - Add explicit Cygwin check to guard WIN32 header inclusion\n - MSVC: Add support for building with NO_MMAP\n - Makefile: keep MSVC and Cygwin configuration separate\n (this branch uses rj/maint-simplify-cygwin-makefile.)\n\nI think J6t was not happy with the tip one.\n\n* cc/bisect-doc (2009-11-08) 1 commit\n - Documentation: add \"Fighting regressions with git bisect\" article\n\nAny comments? Should it go to Documentation/technical instead?\n\n* jn/editor-pager (2009-10-30) 8 commits\n - Provide a build time default-pager setting\n - Provide a build time default-editor setting\n - am -i, git-svn: use \"git var GIT_PAGER\"\n - add -i, send-email, svn, p4, etc: use \"git var GIT_EDITOR\"\n - Teach git var about GIT_PAGER\n - Teach git var about GIT_EDITOR\n - Do not use VISUAL editor on dumb terminals\n - Handle more shell metacharacters in editor names\n\nAny comments?\n\n* sc/difftool-p4merge (2009-10-28) 1 commit\n (merged to 'next' on 2009-10-31 at 194b5c5)\n + mergetool--lib: add p4merge as a pre-configured mergetool option\n\nI do not do p4 nor use difftool, so it's much easier for me to merge this\nto 'master' and wait for anybody to scream if there is breakage. I'll do\nso, unless I hear objections in a few days.\n\n* sr/vcs-helper (2009-11-06) 12 commits\n - Add Python support library for remote helpers\n - ...\n - Fix memory leak in helper method for disconnect\n\nRe-rolled series that contains Daniel's and Johan's.\nAny comments? Is everybody happy?\n\n* fc/doc-fast-forward (2009-10-24) 1 commit.\n (merged to 'next' on 2009-11-01 at faaad90)\n + Use 'fast-forward' all over the place\n\nSoon in 'master'; carrying this in 'next' for too long is turning out to\nbe quite painful.\n\n* ks/precompute-completion (2009-10-26) 3 commits.\n (merged to 'next' on 2009-10-28 at cd5177f)\n + completion: ignore custom merge strategies when pre-generating\n (merged to 'next' on 2009-10-22 at f46a28a)\n + bug: precomputed completion includes scripts sources\n (merged to 'next' on 2009-10-14 at adf722a)\n + Speedup bash completion loading\n\nWhat's the status of this thing? Last time I polled the list I had an\nimpression that it was not quite ready...\n\n* sp/smart-http (2009-11-09) 34 commits\n - t5551-http-fetch: Work around broken Accept header in libcurl\n - t5551-http-fetch: Work around some libcurl versions\n - http-backend: Protect GIT_PROJECT_ROOT from /../ requests\n - Git-aware CGI to provide dumb HTTP transport\n (merged to 'next' on 2009-11-06 at 666837c)\n + http-backend: Test configuration options\n + ...\n + http-push: fix check condition on http.c::finish_http_pack_request()\n\nThe tip ones are workarounds to the issues identified by somebody without\na real name (I do not remember---I am bad at people's names even when they\nare real).\n\n* ef/msys-imap (2009-10-22) 9 commits.\n (merged to 'next' on 2009-10-31 at 8630603)\n + Windows: use BLK_SHA1 again\n + MSVC: Enable OpenSSL, and translate -lcrypto\n + mingw: enable OpenSSL\n + mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle\n + imap-send: build imap-send on Windows\n + imap-send: fix compilation-error on Windows\n + imap-send: use run-command API for tunneling\n + imap-send: use separate read and write fds\n + imap-send: remove useless uid code\n\nSoon in 'master', unless I hear objections from msys folks or imap-send\nusers.\n\n* nd/sparse (2009-08-20) 19 commits.\n - sparse checkout: inhibit empty worktree\n - ...\n - update-index: refactor mark_valid() in preparation for new options\n\nThe latest update I didn't look at very closely but I had an impression\nthat it was touching very generic codepath that would affect non sparse\ncases, iow the patch looked very scary (the entire series already is).\n"},{"id":"127346","messageId":"1257957131-sup-497@ntdws12.chass.utoronto.ca","threadId":"21584","inReplyTo":"7vbpj9s8vk.fsf@alter.siamese.dyndns.org","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Ben Walton","fromEmail":"bwalton@artsci.utoronto.ca","sentAt":"2009-11-11T16:33:37Z","receivedAt":"2009-11-11T16:33:37Z","isPatch":false,"sender":{"key":"bdwalton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/396061?v=4"},"body":"Excerpts from Junio C Hamano's message of Wed Nov 11 04:34:07 -0500 2009:\n\n> * bw/autoconf-more (2009-11-04) 2 commits\n> - configure: add settings for gitconfig, editor and pager\n> - configure: add macro to set arbitrary make variables\n\nThe only note here is that these patches are dependent on the ones in\njn/editor-pager, so if that doesn't get merged, this shouldn't\neither. From my POV, jn/editor-pager does what I was after, so I'm\nhappy.\n\nThanks\n-Ben\n-- \nBen Walton\nSystems Programmer - CHASS\nUniversity of Toronto\nC:416.407.5610 | W:416.978.4302\n\nGPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu\nContact me to arrange for a CAcert assurance meeting.\n"},{"id":"127351","messageId":"200911111807.32835.johan@herland.net","threadId":"21584","inReplyTo":"7vbpj9s8vk.fsf@alter.siamese.dyndns.org","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-11-11T17:07:32Z","receivedAt":"2009-11-11T17:07:32Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 11 November 2009, Junio C Hamano wrote:\n> * jh/notes (2009-10-09) 22 commits.\n> - fast-import: Proper notes tree manipulation using the notes API\n> - ...\n> - Notes API: get_commit_notes() -> format_note() + remove the commit\n> restriction (merged to 'next' on 2009-11-01 at 948327a)\n> + Add selftests verifying concatenation of multiple notes for the\n> same commit + ...\n> + Introduce commit notes\n>\n> I somehow thought that the later API part was waiting for updates but\n> nothing seems to be happening.\n\nSorry for the silence, I've been out with the flu, and been caught up \nwith meatspace issues in general. Will try to send another iteration of \nthe later API part in a few days.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"127356","messageId":"fabb9a1e0911110957k599ac3dfmd1a44a0499c72b2d@mail.gmail.com","threadId":"21584","inReplyTo":"7vbpj9s8vk.fsf@alter.siamese.dyndns.org","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-11T17:57:24Z","receivedAt":"2009-11-11T17:57:24Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Nov 11, 2009 at 10:34, Junio C Hamano wrote:\n> * sr/gfi-options (2009-09-06) 6 commits.\n>  - fast-import: test the new option command\n>  - ...\n>  - fast-import: put option parsing code in separate functions\n>\n> It seemed to be moving again soon, but nothing has happened yet...\n\nI ran out of git time due to the start of my uni's next quarter, this\nis next on my to-do list though, as my remote helper depends on it.\n\n> * sr/vcs-helper (2009-11-06) 12 commits\n>  - Add Python support library for remote helpers\n>  - ...\n>  - Fix memory leak in helper method for disconnect\n>\n> Re-rolled series that contains Daniel's and Johan's.\n> Any comments?  Is everybody happy?\n\nDaniel, are you going to send a follow-up to the memory-leaking patch?\nIf not, this needs to stay out of next until I have time to do so. My\ngitdir patch might need to be evicted as it is connected to\nsr/gfi-options which is not yet done. Also, we need to update the\ndocumentation, but I think we can at least start cooking it in next\nwithout these documentation updates?\n\n> * ks/precompute-completion (2009-10-26) 3 commits.\n>  (merged to 'next' on 2009-10-28 at cd5177f)\n>  + completion: ignore custom merge strategies when pre-generating\n>  (merged to 'next' on 2009-10-22 at f46a28a)\n>  + bug: precomputed completion includes scripts sources\n>  (merged to 'next' on 2009-10-14 at adf722a)\n>  + Speedup bash completion loading\n>\n> What's the status of this thing?  Last time I polled the list I had an\n> impression that it was not quite ready...\n\nDoes the current version require me to 'cd contrib/completion && make'\neach time we update completion? If so, that's a (very annoying)\nregression that needs to be fixed before it's merged to master IMHO.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"127360","messageId":"20091111184215.GG27518@vidovic","threadId":"21584","inReplyTo":"7vbpj9s8vk.fsf@alter.siamese.dyndns.org","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2009-11-11T18:42:15Z","receivedAt":"2009-11-11T18:42:15Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 11/11/09, Junio C Hamano wrote:\n\n> I'll do the full-list at the end of my git Wednesday, but here are the\n> current highlights I am sending out to hear opinions from people.\n\nA bit OT, I've noticed the following output today:\n\n % git clone git://repo.or.cz/girocco.git\n Initialized empty Git repository in /home/nicolas/dev/official_packages/girocco/.git/\n remote: Counting objects: 3017, done.\n g objects: 100% (994/994), done.\n remote: Total 3017 (delta 1911), reused 2988 (delta 1896)\n Receiving objects: 100% (3017/3017), 403.99 KiB | 309 KiB/s, done.\n Resolving deltas: 100% (1911/1911), done.\n %\n\nNotice the \"g \" at the begining at the 3th line. This is reproducible.\n\n % git --version\n git version 1.6.5.2.352.g8b8744\n\n\nI can provide more test or bissect it if wanted.\n\n-- \nNicolas Sebrecht\n"},{"id":"127361","messageId":"alpine.LNX.2.00.0911111259520.14365@iabervon.org","threadId":"21584","inReplyTo":"fabb9a1e0911110957k599ac3dfmd1a44a0499c72b2d@mail.gmail.com","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-11-11T18:45:50Z","receivedAt":"2009-11-11T18:45:50Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 11 Nov 2009, Sverre Rabbelier wrote:\n\n> Heya,\n> \n> On Wed, Nov 11, 2009 at 10:34, Junio C Hamano wrote:\n> > * sr/gfi-options (2009-09-06) 6 commits.\n> >  - fast-import: test the new option command\n> >  - ...\n> >  - fast-import: put option parsing code in separate functions\n> >\n> > It seemed to be moving again soon, but nothing has happened yet...\n> \n> I ran out of git time due to the start of my uni's next quarter, this\n> is next on my to-do list though, as my remote helper depends on it.\n> \n> > * sr/vcs-helper (2009-11-06) 12 commits\n> >  - Add Python support library for remote helpers\n> >  - ...\n> >  - Fix memory leak in helper method for disconnect\n> >\n> > Re-rolled series that contains Daniel's and Johan's.\n> > Any comments?  Is everybody happy?\n> \n> Daniel, are you going to send a follow-up to the memory-leaking patch?\n> If not, this needs to stay out of next until I have time to do so. My\n> gitdir patch might need to be evicted as it is connected to\n> sr/gfi-options which is not yet done. Also, we need to update the\n> documentation, but I think we can at least start cooking it in next\n> without these documentation updates?\n\nOkay, finally got to it just now. This is entirely untested (because I \ndon't have anything that uses it), but it compiles and should be correct. \nIt would be nice to get a clean bill of health on it from valgrind.\n\nIf it works, please squash it into my other patch, keep that commit \nmessage, and add my sign-off.\n\ncommit 5fdebd88a8e5c2714470c86a2c13ee2c795210cb\nAuthor: Daniel Barkalow \nDate: Wed Nov 11 13:36:36 2009 -0500\n\n Free memory used by remote helper importing refspecs, document\n \n \"Allow helper to map private ref names into normal names\" was just an\n RFD which turned out to be surprisingly correct. This adds the necessary\n memory-management and documentation, and generally makes it a suitable\n patch.\n \n Signed-off-by: Daniel Barkalow \n\ndiff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt\nindex 2c5130f..f4b6a5a 100644\n--- a/Documentation/git-remote-helpers.txt\n+++ b/Documentation/git-remote-helpers.txt\n@@ -46,7 +46,11 @@ Supported if the helper has the \"fetch\" capability.\n 'import' ::\n \tProduces a fast-import stream which imports the current value\n \tof the named ref. It may additionally import other refs as\n-\tneeded to construct the history efficiently.\n+\tneeded to construct the history efficiently. The script writes\n+\tto a helper-specific private namespace. The value of the named\n+\tref should be written to a location in this namespace derived\n+\tby applying the refspecs from the \"refspec\" capability to the\n+\tname of the ref.\n +\n Supported if the helper has the \"import\" capability.\n \n@@ -67,6 +71,16 @@ CAPABILITIES\n 'import'::\n \tThis helper supports the 'import' command.\n \n+'refspec' 'spec'::\n+\tWhen using the import command, expect the source ref to have\n+\tbeen written to the destination ref. The earliest applicable\n+\trefspec takes precedence. For example\n+\t\"refs/heads/*:refs/svn/origin/branches/*\" means that, after an\n+\t\"import refs/heads/name\", the script has written to\n+\trefs/svn/origin/branches/name. If this capability is used at\n+\tall, it must cover all refs reported by the list command; if\n+\tit is not used, it is effectively \"*:*\"\n+\n REF LIST ATTRIBUTES\n -------------------\n \ndiff --git a/remote.c b/remote.c\nindex 09e14a8..1f7870d 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -673,6 +673,16 @@ static struct refspec *parse_push_refspec(int nr_refspec, const char **refspec)\n \treturn parse_refspec_internal(nr_refspec, refspec, 0, 0);\n }\n \n+void free_refspec(int nr_refspec, struct refspec *refspec)\n+{\n+\tint i;\n+\tfor (i = 0; i < nr_refspec; i++) {\n+\t\tfree(refspec[i].src);\n+\t\tfree(refspec[i].dst);\n+\t}\n+\tfree(refspec);\n+}\n+\n static int valid_remote_nick(const char *name)\n {\n \tif (!name[0] || is_dot_or_dotdot(name))\ndiff --git a/remote.h b/remote.h\nindex c2f920b..f89cb0e 100644\n--- a/remote.h\n+++ b/remote.h\n@@ -91,6 +91,8 @@ void ref_remove_duplicates(struct ref *ref_map);\n int valid_fetch_refspec(const char *refspec);\n struct refspec *parse_fetch_refspec(int nr_refspec, const char **refspec);\n \n+void free_refspec(int nr_refspec, struct refspec *refspecs);\n+\n char *apply_refspecs(struct refspec *refspecs, int nr_refspec,\n \t\t const char *name);\n \ndiff --git a/transport-helper.c b/transport-helper.c\nindex 7ea76fd..cea646c 100644\n--- a/transport-helper.c\n+++ b/transport-helper.c\n@@ -72,8 +72,13 @@ static struct child_process *get_helper(struct transport *transport)\n \t\t}\n \t}\n \tif (refspecs) {\n+\t\tint i;\n \t\tdata->refspec_nr = refspec_nr;\n \t\tdata->refspecs = parse_fetch_refspec(refspec_nr, refspecs);\n+\t\tfor (i = 0; i < refspec_nr; i++) {\n+\t\t\tfree((char *)refspecs[i]);\n+\t\t}\n+\t\tfree(refspecs);\n \t}\n \treturn data->helper;\n }\n@@ -90,6 +95,8 @@ static int disconnect_helper(struct transport *transport)\n \t\tfree(data->helper);\n \t\tdata->helper = NULL;\n \t}\n+\tfree_refspec(data->refspec_nr, data->refspecs);\n+\tdata->refspecs = NULL;\n \treturn 0;\n }\n "},{"id":"127362","messageId":"m3pr7osxgv.fsf@localhost.localdomain","threadId":"21584","inReplyTo":"7vbpj9s8vk.fsf@alter.siamese.dyndns.org","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-11T18:54:57Z","receivedAt":"2009-11-11T18:54:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano writes:\n\n> I'll do the full-list at the end of my git Wednesday, but here are the\n> current highlights I am sending out to hear opinions from people.\n> \n> Please note that I haven't caught up with the patches from past 12 hours\n> or so.\n> \n> ----------------------------------------------------------------\n\n> * jn/gitweb-blame (2009-09-01) 5 commits.\n> - gitweb: Minify gitweb.js if JSMIN is defined\n> - gitweb: Create links leading to 'blame_incremental' using JavaScript\n> (merged to 'next' on 2009-10-11 at 73c4a83)\n> + gitweb: Colorize 'blame_incremental' view during processing\n> + ...\n> \n> Ajax-y blame. Any progress or RFH?\n\nI have reordered two top commits (those that are only in 'pu'), but I\ndidn't improve \"Create links...\" commit. Current version works, but\nis suboptimal.\n \nI wonder if Packy has any comments about 'blame_incremental' series...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"127368","messageId":"alpine.LFD.2.00.0911111408380.16711@xanadu.home","threadId":"21584","inReplyTo":"20091111184215.GG27518@vidovic","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-11-11T19:50:22Z","receivedAt":"2009-11-11T19:50:22Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 11 Nov 2009, Nicolas Sebrecht wrote:\n\n> A bit OT, I've noticed the following output today:\n> \n> % git clone git://repo.or.cz/girocco.git\n> Initialized empty Git repository in /home/nicolas/dev/official_packages/girocco/.git/\n> remote: Counting objects: 3017, done.\n> g objects: 100% (994/994), done.\n> remote: Total 3017 (delta 1911), reused 2988 (delta 1896)\n> Receiving objects: 100% (3017/3017), 403.99 KiB | 309 KiB/s, done.\n> Resolving deltas: 100% (1911/1911), done.\n> %\n> \n> Notice the \"g \" at the begining at the 3th line. This is reproducible.\n\nI get much worse:\n\nInitialized empty Git repository in /home/nico/git/girocco/.git/\nremote: Counting objects: 3017, done.\nremote: Compressing objects: 5% (50/994) Receiving objects: 3% (91/3017)\nremote: Compressing objects: 15% (150/994) Receiving objects: 7% (212/3017)\nremote: Compressing oReceiving objects: 14% (423/3017), 76.00 KiB | 135 KiB/s\nremote: Compressing objects: 35Receiving objects: 16% (483/3017), 76.00 KiB |\nremote: Compressing objects: 38% (378/994)Receiving objects: 17% (513/3017), 7\nremote: Compressing objectReceiving objects: 20% (604/3017), 76.00 KiB | 135 Ki\nremote: Compressing objects: 48% (47Receiving objects: 22% (664/3017), 76.00 K\nremote: Compressing objects: 5Receiving objects: 23% (694/3017), 76.00 KiB | 1\nremote: Compressing objects: Receiving objects: 25% (755/3017), 76.00 KiB | 13\nremote: Compressing objects: 84% (835/99Receiving objects: 26% (785/3017), 76.\nremote: Compressing objeReceiving objects: 33% (996/3017), 76.00 KiB | 135 KiB/\nremote: Compressing objects: 94% (Receiving objects: 36% (1087/3017), 76.00 Ki\nremote: Compressing objects: 97% (965/994) Receiving objects: 39% (1177/3017\ng objects: 100% (994/994), done.\nremote: Total 3017 (delta 1911), reused 2988 (delta 1896)\nReceiving objects: 100% (3017/3017), 403.99 KiB | 335 KiB/s, done.\nResolving deltas: 100% (1911/1911), done.\n\nAccording to strace, data from sideband channel #2 (prefixed with \n\"remote: \") pertaining to object compression is printed way after pack \ndata has already started to arrive locally. This is really weird.\n\nAnd this occurs only when fetching from repo.or.cz and not from \ngit.kernel.org for example. So there is something to investigate on the \nserver side. Pasky: anything you changed in your git installation \nlately?\n\n\nNicolas\n"},{"id":"127378","messageId":"20091111210727.GN12890@machine.or.cz","threadId":"21584","inReplyTo":"alpine.LFD.2.00.0911111408380.16711@xanadu.home","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2009-11-11T21:07:27Z","receivedAt":"2009-11-11T21:07:27Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 11, 2009 at 02:50:22PM -0500, Nicolas Pitre wrote:\n> On Wed, 11 Nov 2009, Nicolas Sebrecht wrote:\n> \n> > A bit OT, I've noticed the following output today:\n> > \n> > % git clone git://repo.or.cz/girocco.git\n> > Initialized empty Git repository in /home/nicolas/dev/official_packages/girocco/.git/\n> > remote: Counting objects: 3017, done.\n> > g objects: 100% (994/994), done.\n> > remote: Total 3017 (delta 1911), reused 2988 (delta 1896)\n> > Receiving objects: 100% (3017/3017), 403.99 KiB | 309 KiB/s, done.\n> > Resolving deltas: 100% (1911/1911), done.\n> > %\n> > \n> > Notice the \"g \" at the begining at the 3th line. This is reproducible.\n> \n> I get much worse:\n> \n> Initialized empty Git repository in /home/nico/git/girocco/.git/\n> remote: Counting objects: 3017, done.\n> remote: Compressing objects: 5% (50/994) Receiving objects: 3% (91/3017)\n> remote: Compressing objects: 15% (150/994) Receiving objects: 7% (212/3017)\n> remote: Compressing oReceiving objects: 14% (423/3017), 76.00 KiB | 135 KiB/s\n> remote: Compressing objects: 35Receiving objects: 16% (483/3017), 76.00 KiB |\n> remote: Compressing objects: 38% (378/994)Receiving objects: 17% (513/3017), 7\n> remote: Compressing objectReceiving objects: 20% (604/3017), 76.00 KiB | 135 Ki\n> remote: Compressing objects: 48% (47Receiving objects: 22% (664/3017), 76.00 K\n> remote: Compressing objects: 5Receiving objects: 23% (694/3017), 76.00 KiB | 1\n> remote: Compressing objects: Receiving objects: 25% (755/3017), 76.00 KiB | 13\n> remote: Compressing objects: 84% (835/99Receiving objects: 26% (785/3017), 76.\n> remote: Compressing objeReceiving objects: 33% (996/3017), 76.00 KiB | 135 KiB/\n> remote: Compressing objects: 94% (Receiving objects: 36% (1087/3017), 76.00 Ki\n> remote: Compressing objects: 97% (965/994) Receiving objects: 39% (1177/3017\n> g objects: 100% (994/994), done.\n> remote: Total 3017 (delta 1911), reused 2988 (delta 1896)\n> Receiving objects: 100% (3017/3017), 403.99 KiB | 335 KiB/s, done.\n> Resolving deltas: 100% (1911/1911), done.\n> \n> According to strace, data from sideband channel #2 (prefixed with \n> \"remote: \") pertaining to object compression is printed way after pack \n> data has already started to arrive locally. This is really weird.\n> \n> And this occurs only when fetching from repo.or.cz and not from \n> git.kernel.org for example. So there is something to investigate on the \n> server side. Pasky: anything you changed in your git installation \n> lately?\n\nYes, but nothing should have changed in git-daemon, that's the only part\nof the infrastructure that uses system-wide git (which it perhaps\nshouldn't). I cannot reproduce this problem, though. I have changed\ngit-daemon to use my local git version (about one week old master), does\nthis still happen for you?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nA lot of people have my books on their bookshelves.\nThat's the problem, they need to read them. -- Don Knuth\n"},{"id":"127379","messageId":"alpine.LFD.2.00.0911111617440.16711@xanadu.home","threadId":"21584","inReplyTo":"20091111210727.GN12890@machine.or.cz","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-11-11T21:19:44Z","receivedAt":"2009-11-11T21:19:44Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 11 Nov 2009, Petr Baudis wrote:\n\n> On Wed, Nov 11, 2009 at 02:50:22PM -0500, Nicolas Pitre wrote:\n> > According to strace, data from sideband channel #2 (prefixed with \n> > \"remote: \") pertaining to object compression is printed way after pack \n> > data has already started to arrive locally. This is really weird.\n> > \n> > And this occurs only when fetching from repo.or.cz and not from \n> > git.kernel.org for example. So there is something to investigate on the \n> > server side. Pasky: anything you changed in your git installation \n> > lately?\n> \n> Yes, but nothing should have changed in git-daemon, that's the only part\n> of the infrastructure that uses system-wide git (which it perhaps\n> shouldn't). I cannot reproduce this problem, though. I have changed\n> git-daemon to use my local git version (about one week old master), does\n> this still happen for you?\n\nNo, it doesn't happen anymore.\n\nWhat was the git-daemon version before?\n\n\nNicolas\n"},{"id":"127380","messageId":"20091111212648.GI27518@vidovic","threadId":"21584","inReplyTo":"alpine.LFD.2.00.0911111617440.16711@xanadu.home","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2009-11-11T21:26:48Z","receivedAt":"2009-11-11T21:26:48Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 11/11/09, Nicolas Pitre wrote:\n> On Wed, 11 Nov 2009, Petr Baudis wrote:\n> \n> > Yes, but nothing should have changed in git-daemon, that's the only part\n> > of the infrastructure that uses system-wide git (which it perhaps\n> > shouldn't). I cannot reproduce this problem, though. I have changed\n> > git-daemon to use my local git version (about one week old master), does\n> > this still happen for you?\n> \n> No, it doesn't happen anymore.\n\nI couldn't reproduce it, me neither.\n\n> What was the git-daemon version before?\n\n-- \nNicolas Sebrecht\n"},{"id":"127382","messageId":"20091111214216.GO12890@machine.or.cz","threadId":"21584","inReplyTo":"alpine.LFD.2.00.0911111617440.16711@xanadu.home","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2009-11-11T21:42:16Z","receivedAt":"2009-11-11T21:42:16Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 11, 2009 at 04:19:44PM -0500, Nicolas Pitre wrote:\n> On Wed, 11 Nov 2009, Petr Baudis wrote:\n> \n> > On Wed, Nov 11, 2009 at 02:50:22PM -0500, Nicolas Pitre wrote:\n> > > According to strace, data from sideband channel #2 (prefixed with \n> > > \"remote: \") pertaining to object compression is printed way after pack \n> > > data has already started to arrive locally. This is really weird.\n> > > \n> > > And this occurs only when fetching from repo.or.cz and not from \n> > > git.kernel.org for example. So there is something to investigate on the \n> > > server side. Pasky: anything you changed in your git installation \n> > > lately?\n> > \n> > Yes, but nothing should have changed in git-daemon, that's the only part\n> > of the infrastructure that uses system-wide git (which it perhaps\n> > shouldn't). I cannot reproduce this problem, though. I have changed\n> > git-daemon to use my local git version (about one week old master), does\n> > this still happen for you?\n> \n> No, it doesn't happen anymore.\n> \n> What was the git-daemon version before?\n\n1.5.6.5, the default version in debian lenny\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nA lot of people have my books on their bookshelves.\nThat's the problem, they need to read them. -- Don Knuth\n"},{"id":"127387","messageId":"alpine.LFD.2.00.0911111702130.16711@xanadu.home","threadId":"21584","inReplyTo":"20091111214216.GO12890@machine.or.cz","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-11-11T22:04:54Z","receivedAt":"2009-11-11T22:04:54Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 11 Nov 2009, Petr Baudis wrote:\n\n> On Wed, Nov 11, 2009 at 04:19:44PM -0500, Nicolas Pitre wrote:\n> > On Wed, 11 Nov 2009, Petr Baudis wrote:\n> > \n> > > Yes, but nothing should have changed in git-daemon, that's the only part\n> > > of the infrastructure that uses system-wide git (which it perhaps\n> > > shouldn't). I cannot reproduce this problem, though. I have changed\n> > > git-daemon to use my local git version (about one week old master), does\n> > > this still happen for you?\n> > \n> > No, it doesn't happen anymore.\n> > \n> > What was the git-daemon version before?\n> \n> 1.5.6.5, the default version in debian lenny\n\nGo figure. I don't see anything that would explain the difference in \nbehavior with latest git from a quick look.\n\n\nNicolas\n"},{"id":"127385","messageId":"20091111220832.GA31620@progeny.tock","threadId":"21584","inReplyTo":"fabb9a1e0911110957k599ac3dfmd1a44a0499c72b2d@mail.gmail.com","subject":"ks/precompute-completion","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-11T22:08:32Z","receivedAt":"2009-11-11T22:08:32Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\n>> * ks/precompute-completion (2009-10-26) 3 commits.\n>>  (merged to 'next' on 2009-10-28 at cd5177f)\n>>  + completion: ignore custom merge strategies when pre-generating\n>>  (merged to 'next' on 2009-10-22 at f46a28a)\n>>  + bug: precomputed completion includes scripts sources\n>>  (merged to 'next' on 2009-10-14 at adf722a)\n>>  + Speedup bash completion loading\n>>\n>> What's the status of this thing?  Last time I polled the list I had an\n>> impression that it was not quite ready...\n\nAs a distro user, I don’t think I would be able to use it until there\nis a command to update the installed completion, to call after adding\na new git command to my $PATH. This could mean:\n\n - git-completion.bash.generate learns to read the .in file and\n write the completion script to arbitrary paths (or just always\n uses stdin and stdout?)\n\n - distros install git-completion.bash.{generate,in} to /usr/share/git-core\n\n - distros install a simple completion script to /etc/bash_completion.d\n that passes the buck, e.g.\n\n-- %< --\n# bash completion support for core Git.\n#\n# Run update-git-completion to generate these files.\n#\n__git_user_completion=~/.cache/git-core/git-completion.bash\n__git_system_completion=/var/cache/git-core/git-completion.bash\n\nif test -r \"$__git_user_completion\"\nthen\n\t. \"$__git_user_completion\"\nelif test -r \"$__git_system_completion\"\nthen\n\t. \"$__git_system_completion\"\nfi\n-- >% --\n\n - new update-git-completion script, something like this:\n\n-- %< --\n#!/bin/sh\nUSAGE=\"update-git-completion {--system | --user | }\"\ndatadir=/usr/share/git-core\ndie() {\n\techo >&2 \"$*\"\n\texit 1\n}\n\nif ! test $# -eq 1\nthen\n\tdie \"usage: $USAGE\"\nfi\n\nif test \"$1\" = \"--system\"\nthen\n\toutput=/var/cache/git-core/git-completion.bash\nelif test \"$1\" = \"--user\"\nthen\n\toutput=$HOME/.cache/git-core/git-completion.bash\nelse\n\toutput=$1\nfi\n\nrm -f \"$output+\" || die \"cannot remove $output+\"\nsh \"$datadir\"/git-completion.bash.generate \\\n\t< \"$datadir\"/git-completion.bash.in \\\n\t> \"$output+\" || die \"failed to generate completion script\"\nbash -n \"$output+\" || {\n\trm -f \"$output+\"\n\tdie \"generated script fails syntax check\"\n}\nmv -f \"$output+\" \"$output\" || {\n\trm -f \"$output+\"\n\tdie \"failed to install completion script\"\n}\n-- >% --\n\nThoughts?\n"},{"id":"127390","messageId":"alpine.LFD.2.00.0911111707390.16711@xanadu.home","threadId":"21584","inReplyTo":"20091111214216.GO12890@machine.or.cz","subject":"[PATCH] give priority to progress messages","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-11-11T22:24:42Z","receivedAt":"2009-11-11T22:24:42Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"In theory it is possible for sideband channel #2 to be delayed if\npack data is quick to come up for sideband channel #1. And because\ndata for channel #2 is read only 128 bytes at a time while pack data\nis read 8192 bytes at a time, it is possible for many pack blocks to\nbe sent to the client before the progress message fifo is emptied,\nmaking the situation even worse. This would result in totally garbled\nprogress display on the client's console as local progress gets mixed\nwith partial remote progress lines.\n\nLet's prevent such situations by giving transmission priority to \nprogress messages over pack data at all times.\n\nSigned-off-by: Nicolas Pitre \n---\n\nOn Wed, 11 Nov 2009, Petr Baudis wrote:\n\n> On Wed, Nov 11, 2009 at 04:19:44PM -0500, Nicolas Pitre wrote:\n> > On Wed, 11 Nov 2009, Petr Baudis wrote:\n> > \n> > > On Wed, Nov 11, 2009 at 02:50:22PM -0500, Nicolas Pitre wrote:\n> > > > According to strace, data from sideband channel #2 (prefixed with \n> > > > \"remote: \") pertaining to object compression is printed way after pack \n> > > > data has already started to arrive locally. This is really weird.\n> > > > \n> > > > And this occurs only when fetching from repo.or.cz and not from \n> > > > git.kernel.org for example. So there is something to investigate on the \n> > > > server side. Pasky: anything you changed in your git installation \n> > > > lately?\n> > > \n> > > Yes, but nothing should have changed in git-daemon, that's the only part\n> > > of the infrastructure that uses system-wide git (which it perhaps\n> > > shouldn't). I cannot reproduce this problem, though. I have changed\n> > > git-daemon to use my local git version (about one week old master), does\n> > > this still happen for you?\n> > \n> > No, it doesn't happen anymore.\n> > \n> > What was the git-daemon version before?\n> \n> 1.5.6.5, the default version in debian lenny\n\nI don't see why the issue couldn't happen with latest git as well.\nThis patch however would plug any possibilities for this to happen again \nthough.\n\ndiff --git a/builtin-upload-archive.c b/builtin-upload-archive.c\nindex c4cd1e1..29446e8 100644\n--- a/builtin-upload-archive.c\n+++ b/builtin-upload-archive.c\n@@ -132,7 +132,6 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)\n \n \twhile (1) {\n \t\tstruct pollfd pfd[2];\n-\t\tssize_t processed[2] = { 0, 0 };\n \t\tint status;\n \n \t\tpfd[0].fd = fd1[0];\n@@ -147,15 +146,14 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)\n \t\t\t}\n \t\t\tcontinue;\n \t\t}\n-\t\tif (pfd[0].revents & POLLIN)\n-\t\t\t/* Data stream ready */\n-\t\t\tprocessed[0] = process_input(pfd[0].fd, 1);\n \t\tif (pfd[1].revents & POLLIN)\n \t\t\t/* Status stream ready */\n-\t\t\tprocessed[1] = process_input(pfd[1].fd, 2);\n-\t\t/* Always finish to read data when available */\n-\t\tif (processed[0] || processed[1])\n-\t\t\tcontinue;\n+\t\t\tif (process_input(pfd[1].fd, 2))\n+\t\t\t\tcontinue;\n+\t\tif (pfd[0].revents & POLLIN)\n+\t\t\t/* Data stream ready */\n+\t\t\tif (process_input(pfd[0].fd, 1))\n+\t\t\t\tcontinue;\n \n \t\tif (waitpid(writer, &status, 0) < 0)\n \t\t\terror_clnt(\"%s\", lostchild);\ndiff --git a/upload-pack.c b/upload-pack.c\nindex 70badcf..6bfb500 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -310,6 +310,23 @@ static void create_pack_file(void)\n \t\t\t}\n \t\t\tcontinue;\n \t\t}\n+\t\tif (0 <= pe && (pfd[pe].revents & (POLLIN|POLLHUP))) {\n+\t\t\t/* Status ready; we ship that in the side-band\n+\t\t\t * or dump to the standard error.\n+\t\t\t */\n+\t\t\tsz = xread(pack_objects.err, progress,\n+\t\t\t\t sizeof(progress));\n+\t\t\tif (0 < sz)\n+\t\t\t\tsend_client_data(2, progress, sz);\n+\t\t\telse if (sz == 0) {\n+\t\t\t\tclose(pack_objects.err);\n+\t\t\t\tpack_objects.err = -1;\n+\t\t\t}\n+\t\t\telse\n+\t\t\t\tgoto fail;\n+\t\t\t/* give priority to status messages */\n+\t\t\tcontinue;\n+\t\t}\n \t\tif (0 <= pu && (pfd[pu].revents & (POLLIN|POLLHUP))) {\n \t\t\t/* Data ready; we keep the last byte to ourselves\n \t\t\t * in case we detect broken rev-list, so that we\n@@ -347,21 +364,6 @@ static void create_pack_file(void)\n \t\t\tif (sz < 0)\n \t\t\t\tgoto fail;\n \t\t}\n-\t\tif (0 <= pe && (pfd[pe].revents & (POLLIN|POLLHUP))) {\n-\t\t\t/* Status ready; we ship that in the side-band\n-\t\t\t * or dump to the standard error.\n-\t\t\t */\n-\t\t\tsz = xread(pack_objects.err, progress,\n-\t\t\t\t sizeof(progress));\n-\t\t\tif (0 < sz)\n-\t\t\t\tsend_client_data(2, progress, sz);\n-\t\t\telse if (sz == 0) {\n-\t\t\t\tclose(pack_objects.err);\n-\t\t\t\tpack_objects.err = -1;\n-\t\t\t}\n-\t\t\telse\n-\t\t\t\tgoto fail;\n-\t\t}\n \t}\n \n \tif (finish_command(&pack_objects)) {\n"},{"id":"127490","messageId":"4AFCFF50.5080401@gmail.com","threadId":"21584","inReplyTo":"20091111220832.GA31620@progeny.tock","subject":"Re: ks/precompute-completion","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-13T06:40:16Z","receivedAt":"2009-11-13T06:40:16Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Jonathan Nieder wrote:\n>\n> As a distro user, I don't think I would be able to use it until there\n> is a command to update the installed completion, to call after adding\n> a new git command to my $PATH. This could mean:\n>\n> - git-completion.bash.generate learns to read the .in file and\n> write the completion script to arbitrary paths (or just always\n> uses stdin and stdout?)\n>\n> - distros install git-completion.bash.{generate,in} to /usr/share/git-core\n>\n> - distros install a simple completion script to /etc/bash_completion.d\n> that passes the buck, e.g.\n>\n> \n>\n> Thoughts?\n\nI'm confused. Shouldn't your distro take care of updating the completion \nfor you? And wouldn't update-git-completion be more suited as part of a \nmakefile if it was needed at all?\n"},{"id":"127492","messageId":"20091113070652.GA3907@progeny.tock","threadId":"21584","inReplyTo":"4AFCFF50.5080401@gmail.com","subject":"Re: ks/precompute-completion","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-13T07:06:52Z","receivedAt":"2009-11-13T07:06:52Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Stephen Boyd wrote:\n> Jonathan Nieder wrote:\n>>\n>>As a distro user, I don't think I would be able to use it until there\n>>is a command to update the installed completion, to call after adding\n>>a new git command to my $PATH. This could mean:\n[...]\n> I'm confused. Shouldn't your distro take care of updating the\n> completion for you? And wouldn't update-git-completion be more\n> suited as part of a makefile if it was needed at all?\n\nThe problem is that I have git commands the distro did not install in\nmy $PATH. For example, I currently have git-new-workdir in ~/bin, and\nonce I bzr-fastexport works a little better, I will install git-bzr.\n\nEven without such commands, in many distributions the completion\nshould not be one size fits all, since git-svn (for example) belongs\nto a different package.\n\nI would expect the distribution to take care of populating the initial\ncompletion list and updating it on upgrades.\n\nJonathan\n"},{"id":"127493","messageId":"4AFD06CD.7090003@gmail.com","threadId":"21584","inReplyTo":"20091113070652.GA3907@progeny.tock","subject":"Re: ks/precompute-completion","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-13T07:12:13Z","receivedAt":"2009-11-13T07:12:13Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Jonathan Nieder wrote:\n> Stephen Boyd wrote:\n>> I'm confused. Shouldn't your distro take care of updating the\n>> completion for you? And wouldn't update-git-completion be more\n>> suited as part of a makefile if it was needed at all?\n>\n> The problem is that I have git commands the distro did not install in\n> my $PATH. For example, I currently have git-new-workdir in ~/bin, and\n> once I bzr-fastexport works a little better, I will install git-bzr.\n>\n> Even without such commands, in many distributions the completion\n> should not be one size fits all, since git-svn (for example) belongs\n> to a different package\n\nAh ok. I think this proves even more that pregenerating the completion \nis a bad idea. With dynamic population we don't have these problems and \nit only takes 250ms more to load on a P3 700Mhz.\n\nMaybe we should try and speedup 'git help -a' and 'git merge -s help' \ninstead? Perhaps options for the command/porcelain lists and available \nstrategies formatted for script consumption? I doubt it will be as fast \nas compiling, but every bit helps apparently.\n\nSide Note: Running git merge -s help outside a git repository fails, so \ncaching of the merge strategies isn't very effective.\n"},{"id":"127495","messageId":"20091113085028.GA4804@progeny.tock","threadId":"21584","inReplyTo":"4AFD06CD.7090003@gmail.com","subject":"[PATCH] Speed up bash completion loading","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-13T08:50:28Z","receivedAt":"2009-11-13T08:50:28Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"On my slow laptop (P3 600MHz), system-wide bash completions take\ntoo much time to load (> 2s), and a significant fraction of this\ntime is spent loading git-completion.bash:\n\n$ time bash -c \". ./git-completion.bash\" # hot cache, before this patch\n\nreal 0m0.509s\nuser 0m0.310s\nsys 0m0.180s\n\nKirill tracked down that the most time is spent warming up\nmerge_strategy, all_command & porcelain_command caches.\n\nSince git is not used in each and every interactive xterm, it\nseems best to load completion support with cold caches, and then\nload each needed thing lazily. This has most of the speed\nadvantage of pre-generating everything at build time, without the\ncomplication of figuring out at build time what commands will be\navailable at run time.\n\nThe result is that loading completion is significantly faster\nnow:\n\n$ time bash -c \". ./git-completion.bash\" # cold cache, after this patch\n\nreal 0m0.171s\nuser 0m0.060s\nsys 0m0.040s\n\nSuggested-by: Kirill Smelkov \nCc: Shawn O. Pearce \nCc: Stephen Boyd \nCc: Sverre Rabbelier \nCc: Junio C Hamano \nSigned-off-by: Jonathan Nieder \n---\nStephen Boyd wrote:\n\n> Ah ok. I think this proves even more that pregenerating the\n> completion is a bad idea. With dynamic population we don't have\n> these problems and it only takes 250ms more to load on a P3 700Mhz.\n\nHmm, 250 ms is a lot.\n\nStrictly speaking, even with the existing completion script, it might\nbe nice to provide a \"hash -r\"-like command to bring the caches up to\ndate. Such a function could be:\n\ngit-completion-rehash ()\n{\n\t__git_compute_all_commands\n\t__git_compute_merge_strategies\n\t__git_compute_porcelain_commands\n}\n\nBut that is a separate topic.\n\n contrib/completion/git-completion.bash | 35 +++++++++++++++++--------------\n 1 files changed, 19 insertions(+), 16 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 9e8b607..7088ec7 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -330,10 +330,9 @@ __git_list_merge_strategies ()\n \t}'\n }\n \n-__git_merge_strategies ()\n+__git_compute_merge_strategies ()\n {\n-\t: ${__git_merge_strategylist:=$(__git_list_merge_strategies)}\n-\techo \"$__git_merge_strategylist\"\n+\t: ${__git_merge_strategies=$(__git_list_merge_strategies)}\n }\n \n __git_complete_file ()\n@@ -468,15 +467,16 @@ __git_complete_remote_or_refspec ()\n \n __git_complete_strategy ()\n {\n+\t__git_compute_merge_strategies\n \tcase \"${COMP_WORDS[COMP_CWORD-1]}\" in\n \t-s|--strategy)\n-\t\t__gitcomp \"$(__git_merge_strategies)\"\n+\t\t__gitcomp \"$__git_merge_strategies\"\n \t\treturn 0\n \tesac\n \tlocal cur=\"${COMP_WORDS[COMP_CWORD]}\"\n \tcase \"$cur\" in\n \t--strategy=*)\n-\t\t__gitcomp \"$(__git_merge_strategies)\" \"\" \"${cur##--strategy=}\"\n+\t\t__gitcomp \"$__git_merge_strategies\" \"\" \"${cur##--strategy=}\"\n \t\treturn 0\n \t\t;;\n \tesac\n@@ -495,16 +495,16 @@ __git_list_all_commands ()\n \tdone\n }\n \n-__git_all_commands ()\n+__git_compute_all_commands ()\n {\n-\t: ${__git_all_commandlist:=$(__git_list_all_commands)}\n-\techo \"$__git_all_commandlist\"\n+\t: ${__git_all_commands=$(__git_list_all_commands)}\n }\n \n __git_list_porcelain_commands ()\n {\n \tlocal i IFS=\" \"$'\\n'\n-\tfor i in \"help\" $(__git_all_commands)\n+\t__git_compute_all_commands\n+\tfor i in \"help\" $__git_all_commands\n \tdo\n \t\tcase $i in\n \t\t*--*) : helper pattern;;\n@@ -586,10 +586,9 @@ __git_list_porcelain_commands ()\n \tdone\n }\n \n-__git_porcelain_commands ()\n+__git_compute_porcelain_commands ()\n {\n-\t: ${__git_porcelain_commandlist:=$(__git_list_porcelain_commands)}\n-\techo \"$__git_porcelain_commandlist\"\n+\t: ${__git_porcelain_commands=$(__git_list_porcelain_commands)}\n }\n \n __git_aliases ()\n@@ -1082,7 +1081,8 @@ _git_help ()\n \t\treturn\n \t\t;;\n \tesac\n-\t__gitcomp \"$(__git_all_commands)\n+\t__git_compute_all_commands\n+\t__gitcomp \"__git_all_commands\n \t\tattributes cli core-tutorial cvs-migration\n \t\tdiffcore gitk glossary hooks ignore modules\n \t\trepository-layout tutorial tutorial-2\n@@ -1438,7 +1438,8 @@ _git_config ()\n \t\treturn\n \t\t;;\n \tpull.twohead|pull.octopus)\n-\t\t__gitcomp \"$(__git_merge_strategies)\"\n+\t\t__git_compute_merge_strategies\n+\t\t__gitcomp \"$__git_merge_strategies\"\n \t\treturn\n \t\t;;\n \tcolor.branch|color.diff|color.interactive|\\\n@@ -1539,7 +1540,8 @@ _git_config ()\n \tpager.*)\n \t\tlocal pfx=\"${cur%.*}.\"\n \t\tcur=\"${cur#*.}\"\n-\t\t__gitcomp \"$(__git_all_commands)\" \"$pfx\" \"$cur\"\n+\t\t__git_compute_all_commands\n+\t\t__gitcomp \"__git_all_commands\" \"$pfx\" \"$cur\"\n \t\treturn\n \t\t;;\n \tremote.*.*)\n@@ -2136,7 +2138,8 @@ _git ()\n \t\t\t--help\n \t\t\t\"\n \t\t\t;;\n-\t\t*) __gitcomp \"$(__git_porcelain_commands) $(__git_aliases)\" ;;\n+\t\t*) __git_compute_porcelain_commands\n+\t\t __gitcomp \"$__git_porcelain_commands $(__git_aliases)\" ;;\n \t\tesac\n \t\treturn\n \tfi\n-- \n1.6.5.2\n"},{"id":"127497","messageId":"20091113090343.GA5355@progeny.tock","threadId":"21584","inReplyTo":"20091113085028.GA4804@progeny.tock","subject":"Re: [PATCH] Speed up bash completion loading","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-13T09:03:56Z","receivedAt":"2009-11-13T09:03:56Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"On my slow laptop (P3 600MHz), system-wide bash completions take\ntoo much time to load (> 2s), and a significant fraction of this\ntime is spent loading git-completion.bash:\n\n$ time bash -c \". ./git-completion.bash\" # hot cache, before this patch\n\nreal 0m0.509s\nuser 0m0.310s\nsys 0m0.180s\n\nKirill noticed that most of the time is spent warming up\nmerge_strategy, all_command & porcelain_command caches.\n\nSince git is not used in each and every interactive xterm, it\nseems best to load completion support with cold caches, and then\nload each needed thing lazily. This has most of the speed\nadvantage of pre-generating everything at build time, without the\ncomplication of figuring out at build time what commands will be\navailable at run time.\n\nThe result is that loading completion is significantly faster\nnow:\n\n$ time bash -c \". ./git-completion.bash\" # cold cache, after this patch\n\nreal 0m0.171s\nuser 0m0.060s\nsys 0m0.040s\n\nSuggested-by: Kirill Smelkov \nCc: Shawn O. Pearce \nCc: Stephen Boyd \nCc: Sverre Rabbelier \nCc: Junio C Hamano \nSigned-off-by: Jonathan Nieder \n---\nJonathan Nieder wrote:\n> Stephen Boyd wrote:\n\n>> Ah ok. I think this proves even more that pregenerating the\n>> completion is a bad idea. With dynamic population we don't have\n>> these problems and it only takes 250ms more to load on a P3\n>> 700Mhz.\n>\n> Hmm, 250 ms is a lot.\n\nHere’s the real patch. Sorry about that.\n\nJonathan\n\n contrib/completion/git-completion.bash | 67 +++++++++++++++----------------\n 1 files changed, 32 insertions(+), 35 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex e3ddecc..7088ec7 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -21,13 +21,7 @@\n # 2) Added the following line to your .bashrc:\n # source ~/.git-completion.sh\n #\n-# 3) You may want to make sure the git executable is available\n-# in your PATH before this script is sourced, as some caching\n-# is performed while the script loads. If git isn't found\n-# at source time then all lookups will be done on demand,\n-# which may be slightly slower.\n-#\n-# 4) Consider changing your PS1 to also show the current branch:\n+# 3) Consider changing your PS1 to also show the current branch:\n # PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n #\n # The argument to __git_ps1 will be displayed only if you\n@@ -324,12 +318,8 @@ __git_remotes ()\n \tdone\n }\n \n-__git_merge_strategies ()\n+__git_list_merge_strategies ()\n {\n-\tif [ -n \"${__git_merge_strategylist-}\" ]; then\n-\t\techo \"$__git_merge_strategylist\"\n-\t\treturn\n-\tfi\n \tgit merge -s help 2>&1 |\n \tsed -n -e '/[Aa]vailable strategies are: /,/^$/{\n \t\ts/\\.$//\n@@ -339,8 +329,11 @@ __git_merge_strategies ()\n \t\tp\n \t}'\n }\n-__git_merge_strategylist=\n-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)\n+\n+__git_compute_merge_strategies ()\n+{\n+\t: ${__git_merge_strategies=$(__git_list_merge_strategies)}\n+}\n \n __git_complete_file ()\n {\n@@ -474,27 +467,24 @@ __git_complete_remote_or_refspec ()\n \n __git_complete_strategy ()\n {\n+\t__git_compute_merge_strategies\n \tcase \"${COMP_WORDS[COMP_CWORD-1]}\" in\n \t-s|--strategy)\n-\t\t__gitcomp \"$(__git_merge_strategies)\"\n+\t\t__gitcomp \"$__git_merge_strategies\"\n \t\treturn 0\n \tesac\n \tlocal cur=\"${COMP_WORDS[COMP_CWORD]}\"\n \tcase \"$cur\" in\n \t--strategy=*)\n-\t\t__gitcomp \"$(__git_merge_strategies)\" \"\" \"${cur##--strategy=}\"\n+\t\t__gitcomp \"$__git_merge_strategies\" \"\" \"${cur##--strategy=}\"\n \t\treturn 0\n \t\t;;\n \tesac\n \treturn 1\n }\n \n-__git_all_commands ()\n+__git_list_all_commands ()\n {\n-\tif [ -n \"${__git_all_commandlist-}\" ]; then\n-\t\techo \"$__git_all_commandlist\"\n-\t\treturn\n-\tfi\n \tlocal i IFS=\" \"$'\\n'\n \tfor i in $(git help -a|egrep '^ [a-zA-Z0-9]')\n \tdo\n@@ -504,17 +494,17 @@ __git_all_commands ()\n \t\tesac\n \tdone\n }\n-__git_all_commandlist=\n-__git_all_commandlist=\"$(__git_all_commands 2>/dev/null)\"\n \n-__git_porcelain_commands ()\n+__git_compute_all_commands ()\n+{\n+\t: ${__git_all_commands=$(__git_list_all_commands)}\n+}\n+\n+__git_list_porcelain_commands ()\n {\n-\tif [ -n \"${__git_porcelain_commandlist-}\" ]; then\n-\t\techo \"$__git_porcelain_commandlist\"\n-\t\treturn\n-\tfi\n \tlocal i IFS=\" \"$'\\n'\n-\tfor i in \"help\" $(__git_all_commands)\n+\t__git_compute_all_commands\n+\tfor i in \"help\" $__git_all_commands\n \tdo\n \t\tcase $i in\n \t\t*--*) : helper pattern;;\n@@ -595,8 +585,11 @@ __git_porcelain_commands ()\n \t\tesac\n \tdone\n }\n-__git_porcelain_commandlist=\n-__git_porcelain_commandlist=\"$(__git_porcelain_commands 2>/dev/null)\"\n+\n+__git_compute_porcelain_commands ()\n+{\n+\t: ${__git_porcelain_commands=$(__git_list_porcelain_commands)}\n+}\n \n __git_aliases ()\n {\n@@ -1088,7 +1081,8 @@ _git_help ()\n \t\treturn\n \t\t;;\n \tesac\n-\t__gitcomp \"$(__git_all_commands)\n+\t__git_compute_all_commands\n+\t__gitcomp \"__git_all_commands\n \t\tattributes cli core-tutorial cvs-migration\n \t\tdiffcore gitk glossary hooks ignore modules\n \t\trepository-layout tutorial tutorial-2\n@@ -1444,7 +1438,8 @@ _git_config ()\n \t\treturn\n \t\t;;\n \tpull.twohead|pull.octopus)\n-\t\t__gitcomp \"$(__git_merge_strategies)\"\n+\t\t__git_compute_merge_strategies\n+\t\t__gitcomp \"$__git_merge_strategies\"\n \t\treturn\n \t\t;;\n \tcolor.branch|color.diff|color.interactive|\\\n@@ -1545,7 +1540,8 @@ _git_config ()\n \tpager.*)\n \t\tlocal pfx=\"${cur%.*}.\"\n \t\tcur=\"${cur#*.}\"\n-\t\t__gitcomp \"$(__git_all_commands)\" \"$pfx\" \"$cur\"\n+\t\t__git_compute_all_commands\n+\t\t__gitcomp \"__git_all_commands\" \"$pfx\" \"$cur\"\n \t\treturn\n \t\t;;\n \tremote.*.*)\n@@ -2142,7 +2138,8 @@ _git ()\n \t\t\t--help\n \t\t\t\"\n \t\t\t;;\n-\t\t*) __gitcomp \"$(__git_porcelain_commands) $(__git_aliases)\" ;;\n+\t\t*) __git_compute_porcelain_commands\n+\t\t __gitcomp \"$__git_porcelain_commands $(__git_aliases)\" ;;\n \t\tesac\n \t\treturn\n \tfi\n-- \n1.6.5.2\n"},{"id":"127504","messageId":"20091113102955.GA8531@progeny.tock","threadId":"21584","inReplyTo":"20091113090343.GA5355@progeny.tock","subject":"Re: [PATCH] Speed up bash completion loading","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-13T10:29:55Z","receivedAt":"2009-11-13T10:29:55Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n> @@ -1545,7 +1540,8 @@ _git_config ()\n> \tpager.*)\n> \t\tlocal pfx=\"${cur%.*}.\"\n> \t\tcur=\"${cur#*.}\"\n> -\t\t__gitcomp \"$(__git_all_commands)\" \"$pfx\" \"$cur\"\n> +\t\t__git_compute_all_commands\n> +\t\t__gitcomp \"__git_all_commands\" \"$pfx\" \"$cur\"\n> \t\treturn\n> \t\t;;\n> \tremote.*.*)\n\ns/__git_all_commands/\\$__git_all_commands/\n\nYikes. Next patch I’ll let sit for a day.\n\nGood night,\nJonathan\n"},{"id":"127517","messageId":"4AFDC4F3.1050607@gmail.com","threadId":"21584","inReplyTo":"20091113090343.GA5355@progeny.tock","subject":"Re: [PATCH] Speed up bash completion loading","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-13T20:43:31Z","receivedAt":"2009-11-13T20:43:31Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Jonathan Nieder wrote:\n> On my slow laptop (P3 600MHz), system-wide bash completions take\n> too much time to load (> 2s), and a significant fraction of this\n> time is spent loading git-completion.bash:\n> \n[...]\n> Suggested-by: Kirill Smelkov \n> Cc: Shawn O. Pearce \n> Cc: Stephen Boyd \n> Cc: Sverre Rabbelier \n> Cc: Junio C Hamano \n> Signed-off-by: Jonathan Nieder \n> ---\n\nI was under the impression that setting variables during completion \nmeant they were lost at the end of the completion cycle. So to be safe I \nput a 'sleep 5' in __git_list_porcelain_commands() and it only stalled \nme once :-)\n\nI see a small problem, but it can be fixed in another patch. git merge \n-s the first time when you're not in a git directory will \nmake git merge -s after never complete correctly even in a \ngit directory. I guess this become more serious if git isn't in your \npath initially and you do git and then git becomes part of \nyour path and you try again. Here you lose porcelain completion. This is \nprobably never going to happen though, right?\n\nPlus it seems that __git_all_commands is computed twice if I git \n and then git help after. Can that be avoided?\n\nSquashing this on top fixes the two typos you mentioned.\n\n---->8----\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 7088ec7..6817953 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -1082,7 +1082,7 @@ _git_help ()\n ;;\n esac\n __git_compute_all_commands\n- __gitcomp \"__git_all_commands\n+ __gitcomp \"$__git_all_commands\n attributes cli core-tutorial cvs-migration\n diffcore gitk glossary hooks ignore modules\n repository-layout tutorial tutorial-2\n@@ -1541,7 +1541,7 @@ _git_config ()\n local pfx=\"${cur%.*}.\"\n cur=\"${cur#*.}\"\n __git_compute_all_commands\n- __gitcomp \"__git_all_commands\" \"$pfx\" \"$cur\"\n+ __gitcomp \"$__git_all_commands\" \"$pfx\" \"$cur\"\n return\n ;;\n remote.*.*)\n"},{"id":"127540","messageId":"20091114103547.GA1829@progeny.tock","threadId":"21584","inReplyTo":"4AFDC4F3.1050607@gmail.com","subject":"Re: [PATCH] Speed up bash completion loading","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-14T10:35:47Z","receivedAt":"2009-11-14T10:35:47Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Stephen Boyd wrote:\n\n> I was under the impression that setting variables during completion\n> meant they were lost at the end of the completion cycle. So to be\n> safe I put a 'sleep 5' in __git_list_porcelain_commands() and it\n> only stalled me once :-)\n\nClever. :)\n\n> Plus it seems that __git_all_commands is computed twice if I git\n> and then git help after. Can that be avoided?\n\nSounds like a bug; thanks. I’ll squash in something like the following\nfor the next iteration.\n\n-- %< --\nSubject: completion: avoid computing command list twice\n\n__git_all_commands is being computed twice on git with\ngit help after.\n\nSigned-off-by: Jonathan Nieder \n---\n contrib/completion/git-completion.bash | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 6817953..748d4f9 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -588,6 +588,7 @@ __git_list_porcelain_commands ()\n \n __git_compute_porcelain_commands ()\n {\n+\t__git_compute_all_commands\n \t: ${__git_porcelain_commands=$(__git_list_porcelain_commands)}\n }\n \n-- \n1.6.5.2\n"},{"id":"127541","messageId":"20091114110141.GB1829@progeny.tock","threadId":"21584","inReplyTo":"4AFDC4F3.1050607@gmail.com","subject":"Re: [PATCH] Speed up bash completion loading","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-14T11:01:41Z","receivedAt":"2009-11-14T11:01:41Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Stephen Boyd wrote:\n\n> I see a small problem, but it can be fixed in another patch. git\n> merge -s the first time when you're not in a git\n> directory will make git merge -s after never complete\n> correctly even in a git directory.\n\nNot good. I think the sanest thing to do is avoid caching the merge\nstrategy list entirely. Listing merge strategies takes about 100 ms\nhere, which is short enough not to be annoying.\n\n> I guess this become more serious\n> if git isn't in your path initially and you do git and\n> then git becomes part of your path and you try again. Here you lose\n> porcelain completion. This is probably never going to happen though,\n> right?\n\nRight, if this happened to me I would not be too surprised. A similar\nproblem occurs when someone installs a new git subcommand in the\nmiddle of a session. Starting a new session fixes the completion, but\nshould the completion script do something to help people before then?\n\nIt could provide a shell function with a slightly friendlier name than\n\"__git_compute_porcelain_commands\" for the user to invoke explicitly.\n\nIt could retry \"git help -a\" each time completion was needed if it\ngave no results last time (i.e. use \"${__git_all_commands:=\" instead\nof \"${__git_all_commands=\"). This would help with the missing git\nproblem (which seems unusual), but not the missing git-svn.\n\nMaybe it could detect signs of user frustration (repeated attempts to\ncomplete the same thing?) and add to the frustration by silently\nfixing the cache.\n\n-- %< --\nSubject: completion: do not cache merge strategy list\n\nIf \"git merge -s help\" fails the first time we try it (e.g. if you're\nnot in a git directory), git merge -s never completes\ncorrectly within the same session.\n\nReported-by: Stephen Boyd \nSigned-off-by: Jonathan Nieder \n---\n contrib/completion/git-completion.bash | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 748d4f9..634941f 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -332,7 +332,7 @@ __git_list_merge_strategies ()\n \n __git_compute_merge_strategies ()\n {\n-\t: ${__git_merge_strategies=$(__git_list_merge_strategies)}\n+\t__git_merge_strategies=$(__git_list_merge_strategies)\n }\n \n __git_complete_file ()\n-- \n1.6.5.2\n"},{"id":"127547","messageId":"20091114144303.GA31540@neumann","threadId":"21584","inReplyTo":"20091114110141.GB1829@progeny.tock","subject":"Re: [PATCH] Speed up bash completion loading","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2009-11-14T14:43:03Z","receivedAt":"2009-11-14T14:43:03Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi,\n\n\nOn Sat, Nov 14, 2009 at 05:01:41AM -0600, Jonathan Nieder wrote:\n> Stephen Boyd wrote:\n> \n> > I see a small problem, but it can be fixed in another patch. git\n> > merge -s the first time when you're not in a git\n> > directory will make git merge -s after never complete\n> > correctly even in a git directory.\n> \n> Not good. I think the sanest thing to do is avoid caching the merge\n> strategy list entirely. Listing merge strategies takes about 100 ms\n> here, which is short enough not to be annoying.\n> \n> > I guess this become more serious\n> > if git isn't in your path initially and you do git and\n> > then git becomes part of your path and you try again. Here you lose\n> > porcelain completion. This is probably never going to happen though,\n> > right?\n> \n> Right, if this happened to me I would not be too surprised. A similar\n> problem occurs when someone installs a new git subcommand in the\n> middle of a session. Starting a new session fixes the completion, but\n> should the completion script do something to help people before then?\n> \n> It could provide a shell function with a slightly friendlier name than\n> \"__git_compute_porcelain_commands\" for the user to invoke explicitly.\n> \n> It could retry \"git help -a\" each time completion was needed if it\n> gave no results last time (i.e. use \"${__git_all_commands:=\" instead\n> of \"${__git_all_commands=\"). This would help with the missing git\n> problem (which seems unusual), but not the missing git-svn.\n> \n> Maybe it could detect signs of user frustration (repeated attempts to\n> complete the same thing?) and add to the frustration by silently\n> fixing the cache.\n\nWhy? Don't get overly creative here, the command\n\n . /path/to/git-completion.bash\n\nalready does that, plus it fixes the merge strategy completion issue,\nand it's friendly enough for the users.\n\n\nBest,\nGábor\n"},{"id":"127553","messageId":"20091114193300.GA1856@progeny.tock","threadId":"21584","inReplyTo":"20091114144303.GA31540@neumann","subject":"Re: [PATCH] Speed up bash completion loading","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-14T19:33:00Z","receivedAt":"2009-11-14T19:33:00Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Gábor,\n\nSZEDER Gábor wrote:\n\n> Why? Don't get overly creative here, the command\n> \n> . /path/to/git-completion.bash\n> \n> already does that, plus it fixes the merge strategy completion issue,\n> and it's friendly enough for the users.\n\nSounds like a good approach. Squashing this in should get that\nworking again.\n\nSigned-off-by: Jonathan Nieder \n---\nIn this patch, I assume the merge strategy list is not being cached\nany more. Something like this would allow recovering from the merge\nstrategy completion issue, but the victim would have to notice what\nwent wrong first.\n\n contrib/completion/git-completion.bash | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 634941f..ae39373 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -495,6 +495,7 @@ __git_list_all_commands ()\n \tdone\n }\n \n+unset __git_all_commands\n __git_compute_all_commands ()\n {\n \t: ${__git_all_commands=$(__git_list_all_commands)}\n@@ -586,6 +587,7 @@ __git_list_porcelain_commands ()\n \tdone\n }\n \n+unset __git_porcelain_commands\n __git_compute_porcelain_commands ()\n {\n \t__git_compute_all_commands\n-- \n1.6.5.2\n"},{"id":"127571","messageId":"1258242380.9650.90.camel@swboyd-laptop","threadId":"21584","inReplyTo":"20091114110141.GB1829@progeny.tock","subject":"Re: [PATCH] Speed up bash completion loading","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-14T23:46:20Z","receivedAt":"2009-11-14T23:46:20Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"On Sat, 2009-11-14 at 05:01 -0600, Jonathan Nieder wrote:\n> Stephen Boyd wrote:\n> \n> > I see a small problem, but it can be fixed in another patch. git\n> > merge -s the first time when you're not in a git\n> > directory will make git merge -s after never complete\n> > correctly even in a git directory.\n> \n> Not good. I think the sanest thing to do is avoid caching the merge\n> strategy list entirely. Listing merge strategies takes about 100 ms\n> here, which is short enough not to be annoying.\n> \n\nI was thinking of adding an option to git merge (like --strategies) to\nlist the strategies without requiring you to be in a git directory. It\ndoesn't look that easy at first glance so it might not be worth the\ntrouble.\n"},{"id":"127578","messageId":"fabb9a1e0911141807q4be6015bjda4805496be6dbb3@mail.gmail.com","threadId":"21584","inReplyTo":"alpine.LNX.2.00.0911111259520.14365@iabervon.org","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-15T02:07:50Z","receivedAt":"2009-11-15T02:07:50Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Nov 11, 2009 at 19:45, Daniel Barkalow wrote:\n> Okay, finally got to it just now. This is entirely untested (because I\n> don't have anything that uses it), but it compiles and should be correct.\n> It would be nice to get a clean bill of health on it from valgrind.\n\nAfter a lot of manual comparison of valgrind traces (comparing cloning\na local git repo and a local hg repo), I have found the following\nbefore applying your patch (I removed the ==proc== and \"by 0xDEADBEEF\"\nnoise):\n\n 20 bytes in 1 blocks are definitely lost in loss record 24 of 95\n at : calloc (vg_replace_malloc.c:418)\n by : xcalloc (wrapper.c:75)\n by : get_importer (transport-helper.c:132)\n by : fetch_with_import (transport-helper.c:150)\n by : fetch (transport-helper.c:198)\n by : transport_fetch_refs (transport.c:977)\n by : cmd_clone (builtin-clone.c:538)\n by : run_builtin (git.c:251)\n by : handle_internal_command (git.c:396)\n by : run_argv (git.c:438)\n by : main (git.c:509)\n\n 60 bytes in 1 blocks are definitely lost in loss record 43 of 95\n at : realloc (vg_replace_malloc.c:476)\n by : xrealloc (wrapper.c:59)\n by : strbuf_grow (strbuf.c:61)\n by : strbuf_getwholeline (strbuf.c:335)\n by : strbuf_getline (strbuf.c:349)\n by : get_helper (transport-helper.c:52)\n by : get_refs_list (transport-helper.c:228)\n by : transport_get_remote_refs (transport.c:943)\n by : cmd_clone (builtin-clone.c:535)\n by : run_builtin (git.c:251)\n by : handle_internal_command (git.c:396)\n by : run_argv (git.c:438)\n\n 65 bytes in 1 blocks are definitely lost in loss record 47 of 95\n at : malloc (vg_replace_malloc.c:195)\n by : realloc (vg_replace_malloc.c:476)\n by : xrealloc (wrapper.c:59)\n by : strbuf_grow (strbuf.c:61)\n by : strbuf_addf (strbuf.c:199)\n by : get_helper (transport-helper.c:69)\n by : get_refs_list (transport-helper.c:228)\n by : transport_get_remote_refs (transport.c:943)\n by : cmd_clone (builtin-clone.c:535)\n by : run_builtin (git.c:251)\n by : handle_internal_command (git.c:396)\n by : run_argv (git.c:438)\n\n 65 bytes in 1 blocks are definitely lost in loss record 50 of 95\n at : malloc (vg_replace_malloc.c:195)\n by : realloc (vg_replace_malloc.c:476)\n by : xrealloc (wrapper.c:59)\n by : strbuf_grow (strbuf.c:61)\n by : strbuf_addf (strbuf.c:199)\n by : fetch_with_import (transport-helper.c:158)\n by : fetch (transport-helper.c:198)\n by : transport_fetch_refs (transport.c:977)\n by : cmd_clone (builtin-clone.c:538)\n by : run_builtin (git.c:251)\n by : handle_internal_command (git.c:396)\n by : run_argv (git.c:438)\n\n 123 (96 direct, 27 indirect) bytes in 1 blocks are definitely lost\nin loss record 71 of 95\n at : malloc (vg_replace_malloc.c:195)\n by : realloc (vg_replace_malloc.c:476)\n by : xrealloc (wrapper.c:59)\n by : get_helper (transport-helper.c:62)\n by : get_refs_list (transport-helper.c:228)\n by : transport_get_remote_refs (transport.c:943)\n by : cmd_clone (builtin-clone.c:535)\n by : run_builtin (git.c:251)\n by : handle_internal_command (git.c:396)\n by : run_argv (git.c:438)\n by : main (git.c:509)\n\nAnnotated with the relevant source and my comments:\n by : get_importer (transport-helper.c:132)\n\tfastimport->argv = xcalloc(5, sizeof(*fastimport->argv));\n\nYou never free fastimport->argv.\n\n by : get_helper (transport-helper.c:52)\n\t\tif (strbuf_getline(&buf, file, '\\n') == EOF)\n\nYou never strbuf_release(&buf).\n\n by : get_helper (transport-helper.c:69)\n\t\t\tstrbuf_addf(&gitdir, \"gitdir %s\\n\", get_git_dir());\n\nI do strbuf_reset(&gitdir), which should of course be\nstrbuf_release(&gitdir), oops.\n\n by : fetch_with_import (transport-helper.c:158)\n\t\tstrbuf_addf(&buf, \"import %s\\n\", posn->name);\n\nSame here, you never strbuf_release(&buf).\n\n by : get_helper (transport-helper.c:62)\n\t\t\tALLOC_GROW(refspecs,\n\t\t\t\t refspec_nr + 1,\n\t\t\t\t refspec_alloc);\n\nThis would of course be fixed by your patch.\n\nHowever, applying your patch causes:\nerror: Trying to write ref refs/heads/tip with nonexistant object\n0000000000000000000000000000000000000000\nfatal: Cannot update the ref 'HEAD'.\n\nIf I comment out both new lines in disonnect_helper like so fixes that:\n\t//free_refspec(data->refspec_nr, data->refspecs);\n\t//data->refspecs = NULL;\n\nCommenting out only one of the two makes the error return, any idea's?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"127579","messageId":"alpine.LNX.2.00.0911142145571.14365@iabervon.org","threadId":"21584","inReplyTo":"fabb9a1e0911141807q4be6015bjda4805496be6dbb3@mail.gmail.com","subject":"Re: excerpts from tomorrow's \"What's cooking\" draft","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-11-15T02:49:51Z","receivedAt":"2009-11-15T02:49:51Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 15 Nov 2009, Sverre Rabbelier wrote:\n\n> Heya,\n> \n> On Wed, Nov 11, 2009 at 19:45, Daniel Barkalow wrote:\n> > Okay, finally got to it just now. This is entirely untested (because I\n> > don't have anything that uses it), but it compiles and should be correct.\n> > It would be nice to get a clean bill of health on it from valgrind.\n> \n> After a lot of manual comparison of valgrind traces (comparing cloning\n> a local git repo and a local hg repo), I have found the following\n> before applying your patch (I removed the ==proc== and \"by 0xDEADBEEF\"\n> noise):\n> \n> 20 bytes in 1 blocks are definitely lost in loss record 24 of 95\n> at : calloc (vg_replace_malloc.c:418)\n> by : xcalloc (wrapper.c:75)\n> by : get_importer (transport-helper.c:132)\n> by : fetch_with_import (transport-helper.c:150)\n> by : fetch (transport-helper.c:198)\n> by : transport_fetch_refs (transport.c:977)\n> by : cmd_clone (builtin-clone.c:538)\n> by : run_builtin (git.c:251)\n> by : handle_internal_command (git.c:396)\n> by : run_argv (git.c:438)\n> by : main (git.c:509)\n> \n> 60 bytes in 1 blocks are definitely lost in loss record 43 of 95\n> at : realloc (vg_replace_malloc.c:476)\n> by : xrealloc (wrapper.c:59)\n> by : strbuf_grow (strbuf.c:61)\n> by : strbuf_getwholeline (strbuf.c:335)\n> by : strbuf_getline (strbuf.c:349)\n> by : get_helper (transport-helper.c:52)\n> by : get_refs_list (transport-helper.c:228)\n> by : transport_get_remote_refs (transport.c:943)\n> by : cmd_clone (builtin-clone.c:535)\n> by : run_builtin (git.c:251)\n> by : handle_internal_command (git.c:396)\n> by : run_argv (git.c:438)\n> \n> 65 bytes in 1 blocks are definitely lost in loss record 47 of 95\n> at : malloc (vg_replace_malloc.c:195)\n> by : realloc (vg_replace_malloc.c:476)\n> by : xrealloc (wrapper.c:59)\n> by : strbuf_grow (strbuf.c:61)\n> by : strbuf_addf (strbuf.c:199)\n> by : get_helper (transport-helper.c:69)\n> by : get_refs_list (transport-helper.c:228)\n> by : transport_get_remote_refs (transport.c:943)\n> by : cmd_clone (builtin-clone.c:535)\n> by : run_builtin (git.c:251)\n> by : handle_internal_command (git.c:396)\n> by : run_argv (git.c:438)\n> \n> 65 bytes in 1 blocks are definitely lost in loss record 50 of 95\n> at : malloc (vg_replace_malloc.c:195)\n> by : realloc (vg_replace_malloc.c:476)\n> by : xrealloc (wrapper.c:59)\n> by : strbuf_grow (strbuf.c:61)\n> by : strbuf_addf (strbuf.c:199)\n> by : fetch_with_import (transport-helper.c:158)\n> by : fetch (transport-helper.c:198)\n> by : transport_fetch_refs (transport.c:977)\n> by : cmd_clone (builtin-clone.c:538)\n> by : run_builtin (git.c:251)\n> by : handle_internal_command (git.c:396)\n> by : run_argv (git.c:438)\n> \n> 123 (96 direct, 27 indirect) bytes in 1 blocks are definitely lost\n> in loss record 71 of 95\n> at : malloc (vg_replace_malloc.c:195)\n> by : realloc (vg_replace_malloc.c:476)\n> by : xrealloc (wrapper.c:59)\n> by : get_helper (transport-helper.c:62)\n> by : get_refs_list (transport-helper.c:228)\n> by : transport_get_remote_refs (transport.c:943)\n> by : cmd_clone (builtin-clone.c:535)\n> by : run_builtin (git.c:251)\n> by : handle_internal_command (git.c:396)\n> by : run_argv (git.c:438)\n> by : main (git.c:509)\n> \n> Annotated with the relevant source and my comments:\n> by : get_importer (transport-helper.c:132)\n> \tfastimport->argv = xcalloc(5, sizeof(*fastimport->argv));\n> \n> You never free fastimport->argv.\n> \n> by : get_helper (transport-helper.c:52)\n> \t\tif (strbuf_getline(&buf, file, '\\n') == EOF)\n> \n> You never strbuf_release(&buf).\n> \n> by : get_helper (transport-helper.c:69)\n> \t\t\tstrbuf_addf(&gitdir, \"gitdir %s\\n\", get_git_dir());\n> \n> I do strbuf_reset(&gitdir), which should of course be\n> strbuf_release(&gitdir), oops.\n> \n> by : fetch_with_import (transport-helper.c:158)\n> \t\tstrbuf_addf(&buf, \"import %s\\n\", posn->name);\n> \n> Same here, you never strbuf_release(&buf).\n> \n> by : get_helper (transport-helper.c:62)\n> \t\t\tALLOC_GROW(refspecs,\n> \t\t\t\t refspec_nr + 1,\n> \t\t\t\t refspec_alloc);\n> \n> This would of course be fixed by your patch.\n> \n> However, applying your patch causes:\n> error: Trying to write ref refs/heads/tip with nonexistant object\n> 0000000000000000000000000000000000000000\n> fatal: Cannot update the ref 'HEAD'.\n> \n> If I comment out both new lines in disonnect_helper like so fixes that:\n> \t//free_refspec(data->refspec_nr, data->refspecs);\n> \t//data->refspecs = NULL;\n> \n> Commenting out only one of the two makes the error return, any idea's?\n\nLooks like I'm discarding the information before I use it, instead of \nafter. Try moving those lines to release_helper(), and a \"!data->refspecs \n&&\" to the !prefixcmp(... \"refspec \") if condition. (That is, keep the \nrefspecs from the first call to the helper until the whole thing is \nreleased, and ignore those capabilities in later calls.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"127584","messageId":"20091115065016.GA2849@progeny.tock","threadId":"21584","inReplyTo":"1258242380.9650.90.camel@swboyd-laptop","subject":"Re: [PATCH] Speed up bash completion loading","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-15T06:50:16Z","receivedAt":"2009-11-15T06:50:16Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Stephen Boyd wrote:\n\n> I was thinking of adding an option to git merge (like --strategies) to\n> list the strategies without requiring you to be in a git directory. It\n> doesn't look that easy at first glance so it might not be worth the\n> trouble.\n\nRight, that would require support from run_builtin().\n"},{"id":"127589","messageId":"7vd43krwd0.fsf@alter.siamese.dyndns.org","threadId":"21584","inReplyTo":"20091114110141.GB1829@progeny.tock","subject":"Re: [PATCH] Speed up bash completion loading","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-15T09:05:47Z","receivedAt":"2009-11-15T09:05:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> __git_compute_merge_strategies ()\n> {\n> -\t: ${__git_merge_strategies=$(__git_list_merge_strategies)}\n> +\t__git_merge_strategies=$(__git_list_merge_strategies)\n\nWouldn't\n\n\t: ${__gms:=$(command)}\n\nrun command only until it gives a non-empty string?\n"},{"id":"127601","messageId":"20091115102912.GA4100@progeny.tock","threadId":"21584","inReplyTo":"7vd43krwd0.fsf@alter.siamese.dyndns.org","subject":"[PATCH v2] Speed up bash completion loading","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-15T10:29:13Z","receivedAt":"2009-11-15T10:29:13Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"On my slow laptop (P3 600MHz), system-wide bash completions take\ntoo much time to load (> 2s), and a significant fraction of this\ntime is spent loading git-completion.bash:\n\n$ time bash -c \". ./git-completion.bash\" # hot cache, before this patch\n\nreal 0m0.509s\nuser 0m0.310s\nsys 0m0.180s\n\nKirill noticed that most of the time is spent warming up the\nmerge_strategy, all_command and porcelain_command caches.\n\nSince git is not used in each and every interactive xterm, it\nseems best to load completion support with cold caches and then\nload each needed thing lazily. This has most of the speed\nadvantage of pre-generating everything at build time, without the\ncomplication of figuring out at build time what commands will be\navailable at run time.\n\nThe result is that loading completion is significantly faster\nnow:\n\n$ time bash -c \". ./git-completion.bash\" # cold cache, after this patch\n\nreal 0m0.171s\nuser 0m0.060s\nsys 0m0.040s\n\nSuggested-by: Kirill Smelkov \nCc: Shawn O. Pearce \nCc: Stephen Boyd \nCc: SZEDER Gábor \nCc: Sverre Rabbelier \nSigned-off-by: Jonathan Nieder \n---\nThis version incorporates the small improvements previously sent, plus the\nfollowing nice one (which makes caching merge strategies safe again).\nThanks for the advice, everyone.\n\nJunio C Hamano wrote:\n> Jonathan Nieder writes:\n> \n> > __git_compute_merge_strategies ()\n> > {\n> > -\t: ${__git_merge_strategies=$(__git_list_merge_strategies)}\n> > +\t__git_merge_strategies=$(__git_list_merge_strategies)\n> \n> Wouldn't\n> \n> \t: ${__gms:=$(command)}\n> \n> run command only until it gives a non-empty string?\n\nYes. :)\n\n contrib/completion/git-completion.bash | 76 +++++++++++++++++---------------\n 1 files changed, 41 insertions(+), 35 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex e3ddecc..43d76b7 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -21,13 +21,7 @@\n # 2) Added the following line to your .bashrc:\n # source ~/.git-completion.sh\n #\n-# 3) You may want to make sure the git executable is available\n-# in your PATH before this script is sourced, as some caching\n-# is performed while the script loads. If git isn't found\n-# at source time then all lookups will be done on demand,\n-# which may be slightly slower.\n-#\n-# 4) Consider changing your PS1 to also show the current branch:\n+# 3) Consider changing your PS1 to also show the current branch:\n # PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n #\n # The argument to __git_ps1 will be displayed only if you\n@@ -324,12 +318,8 @@ __git_remotes ()\n \tdone\n }\n \n-__git_merge_strategies ()\n+__git_list_merge_strategies ()\n {\n-\tif [ -n \"${__git_merge_strategylist-}\" ]; then\n-\t\techo \"$__git_merge_strategylist\"\n-\t\treturn\n-\tfi\n \tgit merge -s help 2>&1 |\n \tsed -n -e '/[Aa]vailable strategies are: /,/^$/{\n \t\ts/\\.$//\n@@ -339,8 +329,17 @@ __git_merge_strategies ()\n \t\tp\n \t}'\n }\n-__git_merge_strategylist=\n-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)\n+\n+unset __git_merge_strategies\n+# 'git merge -s help' (and thus detection of the merge strategy\n+# list) fails, unfortunately, if run outside of any git working\n+# tree. __git_merge_strategies is set to the empty string in\n+# that case, and the detection will be repeated the next time it\n+# is needed.\n+__git_compute_merge_strategies ()\n+{\n+\t: ${__git_merge_strategies:=$(__git_list_merge_strategies)}\n+}\n \n __git_complete_file ()\n {\n@@ -474,27 +473,24 @@ __git_complete_remote_or_refspec ()\n \n __git_complete_strategy ()\n {\n+\t__git_compute_merge_strategies\n \tcase \"${COMP_WORDS[COMP_CWORD-1]}\" in\n \t-s|--strategy)\n-\t\t__gitcomp \"$(__git_merge_strategies)\"\n+\t\t__gitcomp \"$__git_merge_strategies\"\n \t\treturn 0\n \tesac\n \tlocal cur=\"${COMP_WORDS[COMP_CWORD]}\"\n \tcase \"$cur\" in\n \t--strategy=*)\n-\t\t__gitcomp \"$(__git_merge_strategies)\" \"\" \"${cur##--strategy=}\"\n+\t\t__gitcomp \"$__git_merge_strategies\" \"\" \"${cur##--strategy=}\"\n \t\treturn 0\n \t\t;;\n \tesac\n \treturn 1\n }\n \n-__git_all_commands ()\n+__git_list_all_commands ()\n {\n-\tif [ -n \"${__git_all_commandlist-}\" ]; then\n-\t\techo \"$__git_all_commandlist\"\n-\t\treturn\n-\tfi\n \tlocal i IFS=\" \"$'\\n'\n \tfor i in $(git help -a|egrep '^ [a-zA-Z0-9]')\n \tdo\n@@ -504,17 +500,18 @@ __git_all_commands ()\n \t\tesac\n \tdone\n }\n-__git_all_commandlist=\n-__git_all_commandlist=\"$(__git_all_commands 2>/dev/null)\"\n \n-__git_porcelain_commands ()\n+unset __git_all_commands\n+__git_compute_all_commands ()\n+{\n+\t: ${__git_all_commands=$(__git_list_all_commands)}\n+}\n+\n+__git_list_porcelain_commands ()\n {\n-\tif [ -n \"${__git_porcelain_commandlist-}\" ]; then\n-\t\techo \"$__git_porcelain_commandlist\"\n-\t\treturn\n-\tfi\n \tlocal i IFS=\" \"$'\\n'\n-\tfor i in \"help\" $(__git_all_commands)\n+\t__git_compute_all_commands\n+\tfor i in \"help\" $__git_all_commands\n \tdo\n \t\tcase $i in\n \t\t*--*) : helper pattern;;\n@@ -595,8 +592,13 @@ __git_porcelain_commands ()\n \t\tesac\n \tdone\n }\n-__git_porcelain_commandlist=\n-__git_porcelain_commandlist=\"$(__git_porcelain_commands 2>/dev/null)\"\n+\n+unset __git_porcelain_commands\n+__git_compute_porcelain_commands ()\n+{\n+\t__git_compute_all_commands\n+\t: ${__git_porcelain_commands=$(__git_list_porcelain_commands)}\n+}\n \n __git_aliases ()\n {\n@@ -1088,7 +1090,8 @@ _git_help ()\n \t\treturn\n \t\t;;\n \tesac\n-\t__gitcomp \"$(__git_all_commands)\n+\t__git_compute_all_commands\n+\t__gitcomp \"$__git_all_commands\n \t\tattributes cli core-tutorial cvs-migration\n \t\tdiffcore gitk glossary hooks ignore modules\n \t\trepository-layout tutorial tutorial-2\n@@ -1444,7 +1447,8 @@ _git_config ()\n \t\treturn\n \t\t;;\n \tpull.twohead|pull.octopus)\n-\t\t__gitcomp \"$(__git_merge_strategies)\"\n+\t\t__git_compute_merge_strategies\n+\t\t__gitcomp \"$__git_merge_strategies\"\n \t\treturn\n \t\t;;\n \tcolor.branch|color.diff|color.interactive|\\\n@@ -1545,7 +1549,8 @@ _git_config ()\n \tpager.*)\n \t\tlocal pfx=\"${cur%.*}.\"\n \t\tcur=\"${cur#*.}\"\n-\t\t__gitcomp \"$(__git_all_commands)\" \"$pfx\" \"$cur\"\n+\t\t__git_compute_all_commands\n+\t\t__gitcomp \"$__git_all_commands\" \"$pfx\" \"$cur\"\n \t\treturn\n \t\t;;\n \tremote.*.*)\n@@ -2142,7 +2147,8 @@ _git ()\n \t\t\t--help\n \t\t\t\"\n \t\t\t;;\n-\t\t*) __gitcomp \"$(__git_porcelain_commands) $(__git_aliases)\" ;;\n+\t\t*) __git_compute_porcelain_commands\n+\t\t __gitcomp \"$__git_porcelain_commands $(__git_aliases)\" ;;\n \t\tesac\n \t\treturn\n \tfi\n-- \n1.6.5.2\n"},{"id":"127655","messageId":"20091116015557.GZ11919@spearce.org","threadId":"21584","inReplyTo":"20091115102912.GA4100@progeny.tock","subject":"Re: [PATCH v2] Speed up bash completion loading","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-11-16T01:55:57Z","receivedAt":"2009-11-16T01:55:57Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jonathan Nieder wrote:\n> Since git is not used in each and every interactive xterm, it\n> seems best to load completion support with cold caches and then\n> load each needed thing lazily. This has most of the speed\n> advantage of pre-generating everything at build time, without the\n> complication of figuring out at build time what commands will be\n> available at run time.\n> \n> Suggested-by: Kirill Smelkov \n> Cc: Shawn O. Pearce \n\nAcked-By: Shawn O. Pearce \n\n-- \nShawn.\n"},{"id":"127665","messageId":"4B010D42.4090902@gmail.com","threadId":"21584","inReplyTo":"20091115102912.GA4100@progeny.tock","subject":"Re: [PATCH v2] Speed up bash completion loading","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-16T08:28:50Z","receivedAt":"2009-11-16T08:28:50Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Jonathan Nieder wrote:\n>\n> Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n>>\n>>> __git_compute_merge_strategies ()\n>>> {\n>>> -\t: ${__git_merge_strategies=$(__git_list_merge_strategies)}\n>>> +\t__git_merge_strategies=$(__git_list_merge_strategies)\n>> Wouldn't\n>>\n>> \t: ${__gms:=$(command)}\n>>\n>> run command only until it gives a non-empty string?\n>\n> Yes. :)\n\nWhy not do this for all of the lists and not just the merge strategies?\n"},{"id":"127792","messageId":"20091118004910.GA5729@progeny.tock","threadId":"21584","inReplyTo":"4B010D42.4090902@gmail.com","subject":"[PATCH v3] Speed up bash completion loading","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2009-11-18T00:49:10Z","receivedAt":"2009-11-18T00:49:10Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Since git is not used in each and every interactive xterm, it\nseems best to load completion support with cold caches and then\nload each needed thing lazily. This has most of the speed\nadvantage of pre-generating everything at build time, without the\ncomplication of figuring out at build time what commands will be\navailable at run time.\n\nOn this slow laptop, this decreases the time to load\ngit-completion.bash from about 500 ms to about 175 ms.\n\nSuggested-by: Kirill Smelkov \nAcked-by: Shawn O. Pearce \nCc: Stephen Boyd \nCc: SZEDER Gábor \nCc: Sverre Rabbelier \nSigned-off-by: Jonathan Nieder \n---\nI do not know whether it is kosher to carry over an ack like this.\nThe interdiff is small, for what it’s worth:\n\n\t$ git branch jn/faster-completion-startup ee41299\n\t$ git diff jn/faster-completion-startup\n\tdiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n\tindex bd22802..f67254d 100755\n\t--- a/contrib/completion/git-completion.bash\n\t+++ b/contrib/completion/git-completion.bash\n\t@@ -330,7 +330,7 @@ __git_list_merge_strategies ()\n\t\t}'\n\t }\n\t \n\t-unset __git_merge_strategies\n\t+__git_merge_strategies=\n\t # 'git merge -s help' (and thus detection of the merge strategy\n\t # list) fails, unfortunately, if run outside of any git working\n\t # tree. __git_merge_strategies is set to the empty string in\n\t@@ -501,10 +501,10 @@ __git_list_all_commands ()\n\t\tdone\n\t }\n\t \n\t-unset __git_all_commands\n\t+__git_all_commands=\n\t __git_compute_all_commands ()\n\t {\n\t-\t: ${__git_all_commands=$(__git_list_all_commands)}\n\t+\t: ${__git_all_commands:=$(__git_list_all_commands)}\n\t }\n\t \n\t __git_list_porcelain_commands ()\n\t@@ -593,11 +593,11 @@ __git_list_porcelain_commands ()\n\t\tdone\n\t }\n\t \n\t-unset __git_porcelain_commands\n\t+__git_porcelain_commands=\n\t __git_compute_porcelain_commands ()\n\t {\n\t\t__git_compute_all_commands\n\t-\t: ${__git_porcelain_commands=$(__git_list_porcelain_commands)}\n\t+\t: ${__git_porcelain_commands:=$(__git_list_porcelain_commands)}\n\t }\n\t \n\t __git_aliases ()\n\nPlease let me know if I have commited a faux pas.\n\nStephen Boyd wrote:\n>> Junio C Hamano wrote:\n\n>>> Wouldn't\n>>>\n>>>\t: ${__gms:=$(command)}\n>>>\n>>> run command only until it gives a non-empty string?\n> \n> Why not do this for all of the lists and not just the merge strategies?\n\nI generally find set-if-unset a little more intuitive. But some users\nmight install and try out git completion before realizing the need to\ninstall git, and in this case set-if-empty gives better behavior.\n\nThanks.\n\n contrib/completion/git-completion.bash | 76 +++++++++++++++++---------------\n 1 files changed, 41 insertions(+), 35 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex e3ddecc..1223a07 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -21,13 +21,7 @@\n # 2) Added the following line to your .bashrc:\n # source ~/.git-completion.sh\n #\n-# 3) You may want to make sure the git executable is available\n-# in your PATH before this script is sourced, as some caching\n-# is performed while the script loads. If git isn't found\n-# at source time then all lookups will be done on demand,\n-# which may be slightly slower.\n-#\n-# 4) Consider changing your PS1 to also show the current branch:\n+# 3) Consider changing your PS1 to also show the current branch:\n # PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n #\n # The argument to __git_ps1 will be displayed only if you\n@@ -324,12 +318,8 @@ __git_remotes ()\n \tdone\n }\n \n-__git_merge_strategies ()\n+__git_list_merge_strategies ()\n {\n-\tif [ -n \"${__git_merge_strategylist-}\" ]; then\n-\t\techo \"$__git_merge_strategylist\"\n-\t\treturn\n-\tfi\n \tgit merge -s help 2>&1 |\n \tsed -n -e '/[Aa]vailable strategies are: /,/^$/{\n \t\ts/\\.$//\n@@ -339,8 +329,17 @@ __git_merge_strategies ()\n \t\tp\n \t}'\n }\n-__git_merge_strategylist=\n-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)\n+\n+__git_merge_strategies=\n+# 'git merge -s help' (and thus detection of the merge strategy\n+# list) fails, unfortunately, if run outside of any git working\n+# tree. __git_merge_strategies is set to the empty string in\n+# that case, and the detection will be repeated the next time it\n+# is needed.\n+__git_compute_merge_strategies ()\n+{\n+\t: ${__git_merge_strategies:=$(__git_list_merge_strategies)}\n+}\n \n __git_complete_file ()\n {\n@@ -474,27 +473,24 @@ __git_complete_remote_or_refspec ()\n \n __git_complete_strategy ()\n {\n+\t__git_compute_merge_strategies\n \tcase \"${COMP_WORDS[COMP_CWORD-1]}\" in\n \t-s|--strategy)\n-\t\t__gitcomp \"$(__git_merge_strategies)\"\n+\t\t__gitcomp \"$__git_merge_strategies\"\n \t\treturn 0\n \tesac\n \tlocal cur=\"${COMP_WORDS[COMP_CWORD]}\"\n \tcase \"$cur\" in\n \t--strategy=*)\n-\t\t__gitcomp \"$(__git_merge_strategies)\" \"\" \"${cur##--strategy=}\"\n+\t\t__gitcomp \"$__git_merge_strategies\" \"\" \"${cur##--strategy=}\"\n \t\treturn 0\n \t\t;;\n \tesac\n \treturn 1\n }\n \n-__git_all_commands ()\n+__git_list_all_commands ()\n {\n-\tif [ -n \"${__git_all_commandlist-}\" ]; then\n-\t\techo \"$__git_all_commandlist\"\n-\t\treturn\n-\tfi\n \tlocal i IFS=\" \"$'\\n'\n \tfor i in $(git help -a|egrep '^ [a-zA-Z0-9]')\n \tdo\n@@ -504,17 +500,18 @@ __git_all_commands ()\n \t\tesac\n \tdone\n }\n-__git_all_commandlist=\n-__git_all_commandlist=\"$(__git_all_commands 2>/dev/null)\"\n \n-__git_porcelain_commands ()\n+__git_all_commands=\n+__git_compute_all_commands ()\n+{\n+\t: ${__git_all_commands:=$(__git_list_all_commands)}\n+}\n+\n+__git_list_porcelain_commands ()\n {\n-\tif [ -n \"${__git_porcelain_commandlist-}\" ]; then\n-\t\techo \"$__git_porcelain_commandlist\"\n-\t\treturn\n-\tfi\n \tlocal i IFS=\" \"$'\\n'\n-\tfor i in \"help\" $(__git_all_commands)\n+\t__git_compute_all_commands\n+\tfor i in \"help\" $__git_all_commands\n \tdo\n \t\tcase $i in\n \t\t*--*) : helper pattern;;\n@@ -595,8 +592,13 @@ __git_porcelain_commands ()\n \t\tesac\n \tdone\n }\n-__git_porcelain_commandlist=\n-__git_porcelain_commandlist=\"$(__git_porcelain_commands 2>/dev/null)\"\n+\n+__git_porcelain_commands=\n+__git_compute_porcelain_commands ()\n+{\n+\t__git_compute_all_commands\n+\t: ${__git_porcelain_commands:=$(__git_list_porcelain_commands)}\n+}\n \n __git_aliases ()\n {\n@@ -1088,7 +1090,8 @@ _git_help ()\n \t\treturn\n \t\t;;\n \tesac\n-\t__gitcomp \"$(__git_all_commands)\n+\t__git_compute_all_commands\n+\t__gitcomp \"$__git_all_commands\n \t\tattributes cli core-tutorial cvs-migration\n \t\tdiffcore gitk glossary hooks ignore modules\n \t\trepository-layout tutorial tutorial-2\n@@ -1444,7 +1447,8 @@ _git_config ()\n \t\treturn\n \t\t;;\n \tpull.twohead|pull.octopus)\n-\t\t__gitcomp \"$(__git_merge_strategies)\"\n+\t\t__git_compute_merge_strategies\n+\t\t__gitcomp \"$__git_merge_strategies\"\n \t\treturn\n \t\t;;\n \tcolor.branch|color.diff|color.interactive|\\\n@@ -1545,7 +1549,8 @@ _git_config ()\n \tpager.*)\n \t\tlocal pfx=\"${cur%.*}.\"\n \t\tcur=\"${cur#*.}\"\n-\t\t__gitcomp \"$(__git_all_commands)\" \"$pfx\" \"$cur\"\n+\t\t__git_compute_all_commands\n+\t\t__gitcomp \"$__git_all_commands\" \"$pfx\" \"$cur\"\n \t\treturn\n \t\t;;\n \tremote.*.*)\n@@ -2142,7 +2147,8 @@ _git ()\n \t\t\t--help\n \t\t\t\"\n \t\t\t;;\n-\t\t*) __gitcomp \"$(__git_porcelain_commands) $(__git_aliases)\" ;;\n+\t\t*) __git_compute_porcelain_commands\n+\t\t __gitcomp \"$__git_porcelain_commands $(__git_aliases)\" ;;\n \t\tesac\n \t\treturn\n \tfi\n-- \n1.6.5.2\n"},{"id":"127795","messageId":"20091118005923.GB11919@spearce.org","threadId":"21584","inReplyTo":"20091118004910.GA5729@progeny.tock","subject":"Re: [PATCH v3] Speed up bash completion loading","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-11-18T00:59:23Z","receivedAt":"2009-11-18T00:59:23Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jonathan Nieder wrote:\n> Since git is not used in each and every interactive xterm, it\n> seems best to load completion support with cold caches and then\n> load each needed thing lazily. This has most of the speed\n> advantage of pre-generating everything at build time, without the\n> complication of figuring out at build time what commands will be\n> available at run time.\n> \n> On this slow laptop, this decreases the time to load\n> git-completion.bash from about 500 ms to about 175 ms.\n> \n> Suggested-by: Kirill Smelkov \n\nYup, still...\n\n> Acked-by: Shawn O. Pearce \n\n:-)\n\n> I do not know whether it is kosher to carry over an ack like this.\n> The interdiff is small, for what it???s worth:\n\nUsually you leave it in if all you've done is address minor reviewer\ncomments and they had actually supplied an Acked-by line for the\nprior version.\n\nIts also usually fine to leave it like this, because there is a\ngood chance that the reviewer will agree with the new version and\nit saves Junio from needing to insert the line himself later.\n\nBut it would be bad form to leave an Acked-by in if there was a major\nrewrite. E.g. this particular fix has gone through some really major\nrework to reach this point, keeping an Acked-by from the very first\n\"speedup loading\" patch (which IIRC computed them at build time) into\nthis one would be quite unfriendly.\n \n-- \nShawn.\n"}]}