{"thread":{"id":"12481","subject":"[PATCH v2 3/3] Teach git-fetch to exploit server side automatic tag following","startedAt":"2008-03-04T03:27:40Z","lastAt":"2008-03-06T04:53:00Z","messageCount":5,"participants":["Shawn O. Pearce","Johannes Schindelin"],"isPatch":true,"patchVersion":2,"patchTotal":3},"messages":[{"id":"70883","messageId":"20080304032740.GC16462@spearce.org","threadId":"12481","inReplyTo":null,"subject":"[PATCH v2 3/3] Teach git-fetch to exploit server side automatic tag following","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-04T03:27:40Z","receivedAt":"2008-03-04T03:27:40Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"If the remote peer upload-pack process supports the auto-include-tag\nprotocol extension then we can avoid running a second fetch cycle\non the client side by letting the server send us the annotated tags\nalong with the objects it is packing for us. In the following graph\nwe can now fetch both \"tag1\" and \"tag2\" on the same connection that\nwe fetched \"master\" from the remote when we only have L available\non the local side:\n\n T - tag1 S - tag2\n / /\n L - o ------ o ------ B\n \\ \\\n \\ \\\n origin/master master\n\nThe objects for \"tag1\" are implicitly downloaded without our direct\nknowledge. The existing \"quickfetch\" optimization within git-fetch\ndiscovers that tag1 is complete after the first connection and does\nnot open a second connection.\n\nSigned-off-by: Shawn O. Pearce \n---\n builtin-fetch.c | 3 +++\n t/t5503-tagfollow.sh | 26 ++++++++++++++++++++++++++\n transport.c | 5 +++++\n transport.h | 3 +++\n 4 files changed, 37 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex 26c3d74..55f611e 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -555,6 +555,8 @@ static int do_fetch(struct transport *transport,\n \t\t\tread_ref(rm->peer_ref->name, rm->peer_ref->old_sha1);\n \t}\n \n+\tif (tags == TAGS_DEFAULT && autotags)\n+\t\ttransport_set_option(transport, TRANS_OPT_FOLLOWTAGS, \"1\");\n \tif (fetch_refs(transport, ref_map)) {\n \t\tfree_refs(ref_map);\n \t\treturn 1;\n@@ -568,6 +570,7 @@ static int do_fetch(struct transport *transport,\n \t\tref_map = NULL;\n \t\tfind_non_local_tags(transport, &ref_map, &tail);\n \t\tif (ref_map) {\n+\t\t\ttransport_set_option(transport, TRANS_OPT_FOLLOWTAGS, NULL);\n \t\t\ttransport_set_option(transport, TRANS_OPT_DEPTH, \"0\");\n \t\t\tfetch_refs(transport, ref_map);\n \t\t}\ndiff --git a/t/t5503-tagfollow.sh b/t/t5503-tagfollow.sh\nindex 45ff982..86e5b9b 100755\n--- a/t/t5503-tagfollow.sh\n+++ b/t/t5503-tagfollow.sh\n@@ -121,4 +121,30 @@ test_expect_success 'fetch B, S (commit and tag : 1 connection)' '\n \tgit diff expect actual\n '\n \n+cat - <expect\n+#S\n+want $B\n+want $S\n+#E\n+EOF\n+test_expect_success 'new clone fetch master and tags' '\n+\tgit branch -D cat\n+\trm -f $U\n+\t(\n+\t\tmkdir clone2 &&\n+\t\tcd clone2 &&\n+\t\tgit init &&\n+\t\tgit remote add origin .. &&\n+\t\tGIT_DEBUG_SEND_PACK=3 git fetch 3>../$U &&\n+\t\ttest $B = $(git rev-parse --verify origin/master) &&\n+\t\ttest $S = $(git rev-parse --verify tag2) &&\n+\t\ttest $B = $(git rev-parse --verify tag2^0) &&\n+\t\ttest $T = $(git rev-parse --verify tag1) &&\n+\t\ttest $A = $(git rev-parse --verify tag1^0)\n+\t) &&\n+\ttest -s $U &&\n+\tcut -d\" \" -f1,2 $U >actual &&\n+\tgit diff expect actual\n+'\n+\n test_done\ndiff --git a/transport.c b/transport.c\nindex 166c1d1..12873db 100644\n--- a/transport.c\n+++ b/transport.c\n@@ -560,6 +560,7 @@ static int close_bundle(struct transport *transport)\n struct git_transport_data {\n \tunsigned thin : 1;\n \tunsigned keep : 1;\n+\tunsigned followtags : 1;\n \tint depth;\n \tstruct child_process *conn;\n \tint fd[2];\n@@ -580,6 +581,9 @@ static int set_git_option(struct transport *connection,\n \t} else if (!strcmp(name, TRANS_OPT_THIN)) {\n \t\tdata->thin = !!value;\n \t\treturn 0;\n+\t} else if (!strcmp(name, TRANS_OPT_FOLLOWTAGS)) {\n+\t\tdata->followtags = !!value;\n+\t\treturn 0;\n \t} else if (!strcmp(name, TRANS_OPT_KEEP)) {\n \t\tdata->keep = !!value;\n \t\treturn 0;\n@@ -628,6 +632,7 @@ static int fetch_refs_via_pack(struct transport *transport,\n \targs.keep_pack = data->keep;\n \targs.lock_pack = 1;\n \targs.use_thin_pack = data->thin;\n+\targs.auto_include_tag = data->followtags;\n \targs.verbose = transport->verbose > 0;\n \targs.depth = data->depth;\n \ndiff --git a/transport.h b/transport.h\nindex 6fb4526..8abfc0a 100644\n--- a/transport.h\n+++ b/transport.h\n@@ -53,6 +53,9 @@ struct transport *transport_get(struct remote *, const char *);\n /* Limit the depth of the fetch if not null */\n #define TRANS_OPT_DEPTH \"depth\"\n \n+/* Aggressively fetch annotated tags if possible */\n+#define TRANS_OPT_FOLLOWTAGS \"followtags\"\n+\n /**\n * Returns 0 if the option was used, non-zero otherwise. Prints a\n * message to stderr if the option is not used.\n-- \n1.5.4.3.529.gb25fb\n"},{"id":"70954","messageId":"alpine.LSU.1.00.0803041512040.22527@racer.site","threadId":"12481","inReplyTo":"20080304032740.GC16462@spearce.org","subject":"Re: [PATCH v2 3/3] Teach git-fetch to exploit server side automatic tag following","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-04T15:12:52Z","receivedAt":"2008-03-04T15:12:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\njust two comments from me for this patch series:\n\n- it's a beaut, and\n\n- should followtags not be the default?\n\nCiao,\nDscho\n\n"},{"id":"71032","messageId":"20080305055659.GD8410@spearce.org","threadId":"12481","inReplyTo":"alpine.LSU.1.00.0803041512040.22527@racer.site","subject":"Re: [PATCH v2 3/3] Teach git-fetch to exploit server side automatic tag following","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-05T05:56:59Z","receivedAt":"2008-03-05T05:56:59Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> just two comments from me for this patch series:\n> \n> - it's a beaut, and\n\nThanks.\n \n> - should followtags not be the default?\n\nNo. Absolutely not.\n\nThe client may not want tag objects from this remote. It might not\nwant those tags for all sorts of reasons. Maybe they are doing a\none-shot pull. Maybe they don't trust this remote. Maybe they trust\nthis remote but this remote is famous for 192M tags containing PDFs\nof photo images of build logs printed out on paper, then photographed\non a wood table and finally scanned in at 600 dpi.\n\nSo it should only be enabled *if* we were willing to open a second\nconnection to this remote to followtags from it. And that's not\na change from prior behavior either, its just faster.\n\n-- \nShawn.\n"},{"id":"71066","messageId":"alpine.LSU.1.00.0803051220360.18836@racer.site","threadId":"12481","inReplyTo":"20080305055659.GD8410@spearce.org","subject":"Re: [PATCH v2 3/3] Teach git-fetch to exploit server side automatic tag following","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-05T11:21:54Z","receivedAt":"2008-03-05T11:21:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 5 Mar 2008, Shawn O. Pearce wrote:\n\n> Johannes Schindelin wrote:\n> \n> > - should followtags not be the default?\n> \n> No. Absolutely not.\n> \n> The client may not want tag objects from this remote. It might not want \n> those tags for all sorts of reasons. Maybe they are doing a one-shot \n> pull. Maybe they don't trust this remote. Maybe they trust this remote \n> but this remote is famous for 192M tags containing PDFs of photo images \n> of build logs printed out on paper, then photographed on a wood table \n> and finally scanned in at 600 dpi.\n\nSorry, I meant to say: \"should the followtags feature not be on by default \nin the circumstances where we would follow tags anyway\"...\n\nMaybe you do that, but I did not see it.\n\n> So it should only be enabled *if* we were willing to open a second \n> connection to this remote to followtags from it. And that's not a \n> change from prior behavior either, its just faster.\n\nThanks,\nDscho\n\n"},{"id":"71184","messageId":"20080306045300.GN8410@spearce.org","threadId":"12481","inReplyTo":"alpine.LSU.1.00.0803051220360.18836@racer.site","subject":"Re: [PATCH v2 3/3] Teach git-fetch to exploit server side automatic tag following","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-06T04:53:00Z","receivedAt":"2008-03-06T04:53:00Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Wed, 5 Mar 2008, Shawn O. Pearce wrote:\n> > Johannes Schindelin wrote:\n> > \n> > > - should followtags not be the default?\n> > \n> > No. Absolutely not.\n> > \n> > The client may not want tag objects from this remote. It might not want \n> > those tags for all sorts of reasons. Maybe they are doing a one-shot \n> > pull. Maybe they don't trust this remote. Maybe they trust this remote \n> > but this remote is famous for 192M tags containing PDFs of photo images \n> > of build logs printed out on paper, then photographed on a wood table \n> > and finally scanned in at 600 dpi.\n> \n> Sorry, I meant to say: \"should the followtags feature not be on by default \n> in the circumstances where we would follow tags anyway\"...\n> \n> Maybe you do that, but I did not see it.\n\nNope. followtags should be on if the client wants tags, and off if\nthe client does not want tags. Its that simple. There's no reason\nfor the client to disable followtags if the server will actually\nsupport it, as disabling it when you do have tags to follow will\nonly cost you extra net latency.\n\n-- \nShawn.\n"}]}