{"thread":{"id":"44999","subject":"git-daemon shallow checkout fail","startedAt":"2017-01-29T00:40:11Z","lastAt":"2017-02-07T22:49:40Z","messageCount":9,"participants":["Bob Proulx","Johannes Schindelin","Jeff King","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"310504","messageId":"20170129002932.GA19359@dismay.proulx.com","threadId":"44999","inReplyTo":null,"subject":"git-daemon shallow checkout fail","fromName":"Bob Proulx","fromEmail":"bob@proulx.com","sentAt":"2017-01-29T00:29:32Z","receivedAt":"2017-01-29T00:40:11Z","isPatch":false,"sender":{"key":"bob@proulx.com","avatar":"https://gravatar.com/avatar/26fddd50bfc4bf6a65df572118e9f22771dae2ecf91b33fb99fc9a360fbfce86?d=mp&s=160"},"body":"I am trying to understand a problem with shallow checkouts through the\ngit-daemon.  The server side fails trying to create a shallow_XXXXXX\nfile in the repository.  But of course it can't due to no permissions\nfrom the git-daemon user.\n\nHowever the problem driving me crazy is that this only fails this way\non one machine.  Unfortunately failing on the machine I need to use.\nIf I try this same setup on any other machine I try then there is no\nfailure and it works okay.  Therefore I conclude that in the failing\ncase it is trying to write a shallow_XXXXXX file in the repository but\nin all of the passing cases it does not.  I browsed through the\ngit-daemon source but couldn't deduce the flow yet.\n\nDoes anyone know why one system would try to create shallow_XXXXXX\nfiles in the repository while another one would not?\n\nTrying to be unambiguous here is my test case:\n\n  mkdir /run/git\n  chmod 755 /run/git\n  chown nobody:root /run/git\n  cd /run/git && env -i HOME=/run/git PATH=/usr/local/bin:/usr/bin:/bin su -s /bin/sh -c \"git-daemon --export-all --base-path=/srv/git --verbose\" nobody\n  [18340] Ready to rumble\n\nThat sets up the test case.  Have any bare git repository in /srv/git\nfor use for cloning.\n\n  git clone --depth 1 git://localhost/test-project.git\n  Cloning into 'test-project'...\n  fatal: The remote end hung up unexpectedly\n  fatal: early EOF\n  fatal: index-pack failed\n\nAnd the server side says:\n\n  [26071] Request upload-pack for '/test-project.git'\n  [26071] fatal: Unable to create temporary file '/srv/git/test-project.git/shallow_xKwnvZ': Permission denied\n  [26055] [26071] Disconnected (with error)\n\nOf course git-daemon running as nobody can't create a temporary file\nshallow_XXXXXX in the /srv/git/test-project.git because it has no\npermissions by design.  But why does this work on other systems and\nnot work on my target system?\n\n  git --version  # from today's git clone build\n  git version 2.11.0.485.g4e59582\n\nThanks!\nBob\n"},{"id":"310533","messageId":"alpine.DEB.2.20.1701301719590.3469@virtualbox","threadId":"44999","inReplyTo":"20170129002932.GA19359@dismay.proulx.com","subject":"Re: git-daemon shallow checkout fail","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-01-30T16:52:16Z","receivedAt":"2017-01-30T16:53:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Bob,\n\nOn Sat, 28 Jan 2017, Bob Proulx wrote:\n\n> And the server side says:\n> \n>   [26071] Request upload-pack for '/test-project.git'\n>   [26071] fatal: Unable to create temporary file '/srv/git/test-project.git/shallow_xKwnvZ': Permission denied\n>   [26055] [26071] Disconnected (with error)\n\nAssuming that you can rebuild your Git with debug symbols and without\noptimization (simply remove the -O2 from CFLAGS in the Makefile, I never\nhad any luck with single-stepping in gdb when compiled with -O2), you\ncould attach gdb to the git-daemon and/or upload-pack process. Setting a\nbreakpoint on die_builtin in the failing process should give you a good\nidea why things are failing, at least looking at the stacktrace.\n\nA few more tidbits from a cursory look at the Git source code with `git\ngrep` and the likes:\n\n- that error message comes from shallow.c's setup_temporary_shallow()\n  function\n\n- that function is only called from fetch-pack and receive-pack, neither\n  of which should be called by upload-pack, so it is a puzzle\n\n- adding a test case to t5570-git-daemon.sh that tests specifically your\n  described scenario seems *not* to fail:\n\n-- snip --\ndiff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh\nindex 225a022e8a..0256c9aded 100755\n--- a/t/t5570-git-daemon.sh\n+++ b/t/t5570-git-daemon.sh\n@@ -186,5 +186,17 @@ test_expect_success 'hostname cannot break out of directory' '\n \t\tgit clone --bare \"$GIT_DAEMON_URL/escape.git\" tmp.git\n '\n \n+test_expect_success POSIXPERM 'shallow clone from read-only server' '\n+\ttest_when_finished \"rm -rf tmp.git\" &&\n+\trepo=\"$GIT_DAEMON_DOCUMENT_ROOT_PATH/readonly.git\" &&\n+\tgit init --bare \"$repo\" &&\n+\tgit push \"$repo\" HEAD &&\n+\t>\"$repo\"/git-daemon-export-ok &&\n+\tchmod a-w \"$repo\" &&\n+\ttest_must_fail \\\n+\t\tenv GIT_OVERRIDE_VIRTUAL_HOST=.. \\\n+\t\tgit clone --depth 1 \"$GIT_DAEMON_URL/readonly.git\" tmp.git\n+'\n+\n stop_git_daemon\n test_done\n-- snap --\n\n- I even modified t/lib-git-daemon.sh to start the daemon as `nobody` and\n  kill it as `root`, and I won't share that patch because it is as\n  ugly, but *even then* the test succeeded.\n\nSo my suspicion is that the repository you try to serve may already be\nshallow, or something else funky is going on that has not been included in\nyour report.\n\nThe most direct way to get to the bottom of this may be to do something\nlike this:\n\n-- snip --\ndiff --git a/shallow.c b/shallow.c\nindex 11f7dde9d9..30f5c96d50 100644\n--- a/shallow.c\n+++ b/shallow.c\n@@ -288,12 +288,18 @@ int write_shallow_commits(struct strbuf *out, int use_pack_protocol,\n \n static struct tempfile temporary_shallow;\n \n+static int debug_me;\n+\n const char *setup_temporary_shallow(const struct sha1_array *extra)\n {\n \tstruct strbuf sb = STRBUF_INIT;\n \tint fd;\n \n \tif (write_shallow_commits(&sb, 0, extra)) {\n+error(\"About to create shallow_XXXXXX: pid = %d\", getpid());\n+while (!debug_me) {\n+\tsleep(1);\n+}\n \t\tfd = xmks_tempfile(&temporary_shallow, git_path(\"shallow_XXXXXX\"));\n \n \t\tif (write_in_full(fd, sb.buf, sb.len) != sb.len)\n-- snap --\n\nThen let it run, wait for the error message \"About to create\nshallow_XXXXXX\" and then attach with a gdb started as nobody via `attach\n<pid>` to see the stack trace.\n\nThat should give you an idea where that code path is hit (unexpectedly).\n\nCiao,\nJohannes\n"},{"id":"310539","messageId":"20170130172730.x5guphyqf5fsfi7m@sigill.intra.peff.net","threadId":"44999","inReplyTo":"20170129002932.GA19359@dismay.proulx.com","subject":"Re: git-daemon shallow checkout fail","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-01-30T17:27:31Z","receivedAt":"2017-01-30T17:27:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jan 28, 2017 at 05:29:32PM -0700, Bob Proulx wrote:\n\n> However the problem driving me crazy is that this only fails this way\n> on one machine.  Unfortunately failing on the machine I need to use.\n> If I try this same setup on any other machine I try then there is no\n> failure and it works okay.  Therefore I conclude that in the failing\n> case it is trying to write a shallow_XXXXXX file in the repository but\n> in all of the passing cases it does not.  I browsed through the\n> git-daemon source but couldn't deduce the flow yet.\n> \n> Does anyone know why one system would try to create shallow_XXXXXX\n> files in the repository while another one would not?\n\nIt depends on the git version on the server. The interesting code is in\nupload-pack.c, which is spawned by git-daemon to serve a fetch or clone\nrequest.\n\nSee commit b790e0f67 (upload-pack: send shallow info over stdin to\npack-objects, 2014-03-11), which lays out the history. Since that commit\n(in git v2.0.0), there should be no tmpfile needed.\n\n> Of course git-daemon running as nobody can't create a temporary file\n> shallow_XXXXXX in the /srv/git/test-project.git because it has no\n> permissions by design.  But why does this work on other systems and\n> not work on my target system?\n> \n>   git --version  # from today's git clone build\n>   git version 2.11.0.485.g4e59582\n\nThis shouldn't be happening with git v2.11. Are you sure that the \"git\ndaemon\" invocation is running that same version? I notice you set up a\nrestricted PATH. Is it possible that /usr/local/bin or /usr/bin has an\nolder version of git?\n\n-Peff\n"},{"id":"310718","messageId":"CACsJy8DED9WRr_T6g43bxHUGQYVnfaTx15hqSGiiajvi0TxtuA@mail.gmail.com","threadId":"44999","inReplyTo":"20170130172730.x5guphyqf5fsfi7m@sigill.intra.peff.net","subject":"Re: git-daemon shallow checkout fail","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-02-02T09:26:07Z","receivedAt":"2017-02-02T09:26:50Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Jan 31, 2017 at 12:27 AM, Jeff King <peff@peff.net> wrote:\n> On Sat, Jan 28, 2017 at 05:29:32PM -0700, Bob Proulx wrote:\n>\n>> However the problem driving me crazy is that this only fails this way\n>> on one machine.  Unfortunately failing on the machine I need to use.\n>> If I try this same setup on any other machine I try then there is no\n>> failure and it works okay.  Therefore I conclude that in the failing\n>> case it is trying to write a shallow_XXXXXX file in the repository but\n>> in all of the passing cases it does not.  I browsed through the\n>> git-daemon source but couldn't deduce the flow yet.\n>>\n>> Does anyone know why one system would try to create shallow_XXXXXX\n>> files in the repository while another one would not?\n>\n> It depends on the git version on the server. The interesting code is in\n> upload-pack.c, which is spawned by git-daemon to serve a fetch or clone\n> request.\n>\n> See commit b790e0f67 (upload-pack: send shallow info over stdin to\n> pack-objects, 2014-03-11), which lays out the history. Since that commit\n> (in git v2.0.0), there should be no tmpfile needed.\n\nIt must be it. There's nowhere else that upload-pack can create\nshallow_XXXXXX. (receive-pack and fetch-pack can).\n\n>> Of course git-daemon running as nobody can't create a temporary file\n>> shallow_XXXXXX in the /srv/git/test-project.git because it has no\n>> permissions by design.  But why does this work on other systems and\n>> not work on my target system?\n>>\n>>   git --version  # from today's git clone build\n>>   git version 2.11.0.485.g4e59582\n>\n> This shouldn't be happening with git v2.11. Are you sure that the \"git\n> daemon\" invocation is running that same version? I notice you set up a\n> restricted PATH. Is it possible that /usr/local/bin or /usr/bin has an\n> older version of git?\n\nOne easy way to verify is clone or fetch again with GIT_TRACE_PACKET=1\nsince we send the server's version as a capability since 1.8.0\n-- \nDuy\n"},{"id":"310958","messageId":"20170206170428232901985@bob.proulx.com","threadId":"44999","inReplyTo":"alpine.DEB.2.20.1701301719590.3469@virtualbox","subject":"Re: git-daemon shallow checkout fail","fromName":"Bob Proulx","fromEmail":"bob@proulx.com","sentAt":"2017-02-07T00:27:05Z","receivedAt":"2017-02-07T00:27:12Z","isPatch":false,"sender":{"key":"bob@proulx.com","avatar":"https://gravatar.com/avatar/26fddd50bfc4bf6a65df572118e9f22771dae2ecf91b33fb99fc9a360fbfce86?d=mp&s=160"},"body":"Hello Johannes,\n\nThank you very much for the good hints here.  They are very helpful.\n\nJohannes Schindelin wrote:\n> Assuming that you can rebuild your Git with debug symbols and without\n> optimization (simply remove the -O2 from CFLAGS in the Makefile, I never\n> had any luck with single-stepping in gdb when compiled with -O2), you\n\nI always debug with -g and without -O because otherwise it leads to a\nlot of confusion.  But git-daemon is a forking daemon which makes\ndebugging it with the debugger somewhere more default and requiring\nmore setup to debug past the fork points.  As you note and hint with\nlater setting up an attach point for gdb.\n\n> - that error message comes from shallow.c's setup_temporary_shallow()\n>   function\n\nYes.  I find that too.\n\n> - that function is only called from fetch-pack and receive-pack, neither\n>   of which should be called by upload-pack, so it is a puzzle\n\nThe choice of directionality for upload and download might be\nconfusing me here too.  Since from the client side of things it is a\ndownload.  But on the server side it is an upload.\n\n> - adding a test case to t5570-git-daemon.sh that tests specifically your\n>   described scenario seems *not* to fail:\n\nI have seen some of the patches that seems like should have fixed this\nproblem.  It is perplexing.  But see my next mail on this too.\n\n> - I even modified t/lib-git-daemon.sh to start the daemon as `nobody` and\n>   kill it as `root`, and I won't share that patch because it is as\n>   ugly, but *even then* the test succeeded.\n\nIt succeeds for me on other systems.  It is only the one (where I need\nit) that it is failing.\n\n> So my suspicion is that the repository you try to serve may already be\n> shallow, or something else funky is going on that has not been included in\n> your report.\n\nIt happens to any repository.  I picked a small repository and copied\nit verbatim using rsync to my working environment.  The identical bits\nof a repository copied by rsync work okay on one system but fail on\nthe other.\n\n> The most direct way to get to the bottom of this may be to do something\n> like this:\n...\n>  \tif (write_shallow_commits(&sb, 0, extra)) {\n> +error(\"About to create shallow_XXXXXX: pid = %d\", getpid());\n> +while (!debug_me) {\n> +\tsleep(1);\n> +}\n>  \t\tfd = xmks_tempfile(&temporary_shallow, git_path(\"shallow_XXXXXX\"));\n>  \n>  \t\tif (write_in_full(fd, sb.buf, sb.len) != sb.len)\n> -- snap --\n> \n> Then let it run, wait for the error message \"About to create\n> shallow_XXXXXX\" and then attach with a gdb started as nobody via `attach\n> <pid>` to see the stack trace.\n> \n> That should give you an idea where that code path is hit (unexpectedly).\n\nThat is a good hint.  I will give that a try.  However see my next\nemail for more (confusing) information.\n\nBob\n"},{"id":"310959","messageId":"20170206171225215133282@bob.proulx.com","threadId":"44999","inReplyTo":"CACsJy8DED9WRr_T6g43bxHUGQYVnfaTx15hqSGiiajvi0TxtuA@mail.gmail.com","subject":"Re: git-daemon shallow checkout fail","fromName":"Bob Proulx","fromEmail":"bob@proulx.com","sentAt":"2017-02-07T00:27:47Z","receivedAt":"2017-02-07T00:27:52Z","isPatch":false,"sender":{"key":"bob@proulx.com","avatar":"https://gravatar.com/avatar/26fddd50bfc4bf6a65df572118e9f22771dae2ecf91b33fb99fc9a360fbfce86?d=mp&s=160"},"body":"Duy Nguyen wrote:\n> Jeff King wrote:\n> > It depends on the git version on the server. The interesting code is in\n> > upload-pack.c, which is spawned by git-daemon to serve a fetch or clone\n> > request.\n> >\n> > See commit b790e0f67 (upload-pack: send shallow info over stdin to\n> > pack-objects, 2014-03-11), which lays out the history. Since that commit\n> > (in git v2.0.0), there should be no tmpfile needed.\n> \n> It must be it. There's nowhere else that upload-pack can create\n> shallow_XXXXXX. (receive-pack and fetch-pack can).\n\nI am sure the file creation is there.  Because it isn't being done\nanywhere.  But the problem is before that time period.  By then the\npaths are already set.\n\n> >Bob Proulx wrote:\n> >>   git --version  # from today's git clone build\n> >>   git version 2.11.0.485.g4e59582\n> >\n> > This shouldn't be happening with git v2.11. Are you sure that the \"git\n> > daemon\" invocation is running that same version? I notice you set up a\n> > restricted PATH. Is it possible that /usr/local/bin or /usr/bin has an\n> > older version of git?\n\nI have been starting it with PATH set to my directory.  But given this\nquestion I start it with a full path.\n\n  PATH=~/src/git-stuff/git:$PATH ~/src/git-stuff/git/git-daemon --export-all --base-path=/srv/git --verbose\n\nBut then I worry about the package installed binary still getting\ninvoked with the fork somehow.  Therefore I disable it.  There should\nbe no possibility of it invoking the packaged daemon.  I moved it out\nof the way.\n\n  mv /usr/lib/git-core/git-daemon /usr/lib/git-core/git-daemon.disabled\n\nI can't trivially remove the packaged version because other things\ndepend upon it.  I could get more agressive about disabling it in a\nnon-destructive and reversible way though.\n\n> One easy way to verify is clone or fetch again with GIT_TRACE_PACKET=1\n> since we send the server's version as a capability since 1.8.0\n\nAnd here is the interesting part.  If I read this right the client is\nreporting 1.9.1 from the server!  But how?  \n\n  $ GIT_TRACE_PACKET=1 git clone --depth 1 git://git0.savannah.gnu.org/test-project.git\n  Cloning into 'test-project'...\n  17:20:40.482970 pkt-line.c:46           packet:        clone> git-upload-pack /test-project.git\\0host=git0.savannah.gnu.org\\0\n  17:20:40.590177 pkt-line.c:46           packet:        clone< 34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/1.9.1\n  17:20:40.662623 pkt-line.c:46           packet:        clone< 34e7202270c381f4e5734180dc19426ce69f2e1e refs/heads/master\n  17:20:40.662653 pkt-line.c:46           packet:        clone< 0000\n  17:20:40.663682 pkt-line.c:46           packet:        clone> want 34e7202270c381f4e5734180dc19426ce69f2e1e multi_ack_detailed side-band-64k thin-pack include-tag ofs-delta agent=git/2.1.4\n  17:20:40.663701 pkt-line.c:46           packet:        clone> want 34e7202270c381f4e5734180dc19426ce69f2e1e\n  17:20:40.663713 pkt-line.c:46           packet:        clone> deepen 1\n  17:20:40.663724 pkt-line.c:46           packet:        clone> 0000\n  17:20:40.739502 pkt-line.c:46           packet:        clone< shallow 34e7202270c381f4e5734180dc19426ce69f2e1e\n  17:20:40.854338 pkt-line.c:46           packet:        clone< 0000\n  17:20:40.854360 pkt-line.c:46           packet:        clone> done\n  17:20:40.929349 pkt-line.c:46           packet:        clone< NAK\n  fatal: The remote end hung up unexpectedly\n  fatal: early EOF\n  fatal: index-pack failed\n\nI am assuming that the \"agent=git/1.9.1\" is the evidence that it isn't\nrunning the code that I am trying to make it run?  Of course the\npackaged installed git version is 1.9.1 (from Trisquel 7, an Ubuntu\n14.04 fork) so that matches.  My client is \"agent=git/2.1.4\" (from\nDebian Jessie) so that matches my client end.\n\nTherefore it looks like it is invoking some other command by a hard\ncoded path and avoiding PATH to my development bits.  It must be\ninvoking some other binary.  I will get more agressive about disabling\nthe packaged version and hopefully find out which one.\n\nThank you very much for the good hints here.  They are very helpful.\n\nBob\n"},{"id":"310962","messageId":"20170206174000357620972@bob.proulx.com","threadId":"44999","inReplyTo":"20170206171225215133282@bob.proulx.com","subject":"Re: git-daemon shallow checkout fail","fromName":"Bob Proulx","fromEmail":"bob@proulx.com","sentAt":"2017-02-07T00:56:33Z","receivedAt":"2017-02-07T00:56:39Z","isPatch":false,"sender":{"key":"bob@proulx.com","avatar":"https://gravatar.com/avatar/26fddd50bfc4bf6a65df572118e9f22771dae2ecf91b33fb99fc9a360fbfce86?d=mp&s=160"},"body":"Bob Proulx wrote:\n>   17:20:40.590177 pkt-line.c:46           packet:        clone< 34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/1.9.1\n\nThe evidence of it running the wrong version being the 1.9.1 which is\nnot the bits I built.\n\n> Therefore it looks like it is invoking some other command by a hard\n> coded path and avoiding PATH to my development bits.  It must be\n> invoking some other binary.  I will get more agressive about disabling\n> the packaged version and hopefully find out which one.\n\nI did and of course it is /usr/bin/git-upload-pack and if I disable\nthat binary then git-daemon no longer operates.\n\n  error: cannot run upload-pack: No such file or directory\n\nBut shouldn't it find git-upload-pack from PATH?  Since I have\ngit-upload-pack installed in PATH?  Apparently not.  At least not when\ninvoking as /path/to/git-daemon directly.\n\nIn any case with the all of your very good help, especially the\nversion echo print, guiding me to the problem that I was able to make\nthis work.\n\n  cd /run/git && env -i HOME=/run/git PATH=$HOME/src/git-stuff/git:/usr/bin:/bin $HOME/src/git-stuff/git/git --exec-path=$HOME/src/git-stuff/git daemon --export-all --base-path=/srv/git --verbose\n\nThat works for the git-daemon.  It does not require me to modify\nanything else on the system.  Good enough.  Problem solved.\n\nThanks!\nBob\n"},{"id":"310975","messageId":"CACsJy8D_X7u+kttu=ZD734u6nhR=wjMh0m99RBvm0_FOW74pWA@mail.gmail.com","threadId":"44999","inReplyTo":"20170206174000357620972@bob.proulx.com","subject":"Re: git-daemon shallow checkout fail","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-02-07T11:07:15Z","receivedAt":"2017-02-07T11:07:51Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 7, 2017 at 7:56 AM, Bob Proulx <bob@proulx.com> wrote:\n> Bob Proulx wrote:\n>>   17:20:40.590177 pkt-line.c:46           packet:        clone< 34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/1.9.1\n>\n> The evidence of it running the wrong version being the 1.9.1 which is\n> not the bits I built.\n\nI wonder if we should make this \"git/1.9.1\" information more visible. We could\n\n1) Always print it when cloning\n2) Print it when cloning with -v (printing all capabilities with -v\nmight not be a bad idea)\n3) Include it in error messages when clone/fetch fails\n-- \nDuy\n"},{"id":"311014","messageId":"20170207154512329677197@bob.proulx.com","threadId":"44999","inReplyTo":"CACsJy8D_X7u+kttu=ZD734u6nhR=wjMh0m99RBvm0_FOW74pWA@mail.gmail.com","subject":"Re: git-daemon shallow checkout fail","fromName":"Bob Proulx","fromEmail":"bob@proulx.com","sentAt":"2017-02-07T22:49:27Z","receivedAt":"2017-02-07T22:49:40Z","isPatch":false,"sender":{"key":"bob@proulx.com","avatar":"https://gravatar.com/avatar/26fddd50bfc4bf6a65df572118e9f22771dae2ecf91b33fb99fc9a360fbfce86?d=mp&s=160"},"body":"Duy Nguyen wrote:\n> I wonder if we should make this \"git/1.9.1\" information more visible. We could\n> \n> 1) Always print it when cloning\n> 2) Print it when cloning with -v (printing all capabilities with -v\n> might not be a bad idea)\n> 3) Include it in error messages when clone/fetch fails\n\nI don't think I would want to see it all of the time.  It isn't needed\nall of the time.  But having it printable upon demand is nice.  Being\nable to use GIT_TRACE_PACKET=1 worked very well.  The only thing I\nneeded was to know it was available so that I could use it.  I am not\nsure where that is documented.\n\nTherefore if and only if a change was made I would vote for printing\nonly under --verbose or other explicit other information option.  I\nwould not add it to the normal operation output.\n\nBob\n"}]}