{"thread":{"id":"1374","subject":"send-pack question.","startedAt":"2005-07-31T05:47:51Z","lastAt":"2005-07-31T06:02:57Z","messageCount":2,"participants":["Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6655","messageId":"7v1x5fwmpk.fsf@assigned-by-dhcp.cox.net","threadId":"1374","inReplyTo":null,"subject":"send-pack question.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-31T05:47:51Z","receivedAt":"2005-07-31T05:47:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I have been looking at send-pack because some people seem to\nwant to push into a remote repository that names heads\ndifferently from local.  I have some questions that do not have\nto do with anything about their request, but about what\nthe current code intends to do.\n\n * Right now, \"send-pack --all\" into an empty repository does\n   not do anything, but \"send-pack --all master\" into an empty\n   repository pushes all local heads.  This is because we do not\n   check \"send_all\" when deciding if we want to call try_match\n   on local references.  I am assuming this is an oversight; am\n   I correct?  If so, does the attached patch look OK?\n\n * It appears to me that you can say \"send-pack net\", and\n   depending on how the remote lists its refs, you can end up\n   updating their refs/heads/net or refs/tags/net.  More\n   confusingly, you could say \"send-pack net net\" to update\n   both.  More realistically, you could get confused with a\n   remote that has refs/heads/jgarzik/net and\n   refs/heads/dsmiller/net in this way.  I think it should\n   detect, stop and warn about the ambiguity and require the\n   user to be more explicit.  Am I reading the current code\n   correctly?\n\n   I've always _hated_ the interface to path_match() which\n   pretends to be just a boolean function but actually has a\n   grave side effect, by the way.\n\n---\n# - pu: git-fetch-script http fix.\n# + (working tree)\ndiff --git a/send-pack.c b/send-pack.c\n--- a/send-pack.c\n+++ b/send-pack.c\n@@ -4,7 +4,8 @@\n #include \"pkt-line.h\"\n \n static const char send_pack_usage[] =\n-\"git-send-pack [--exec=git-receive-pack] [host:]directory [heads]*\";\n+\"git-send-pack [--all] [--exec=git-receive-pack] <remote> [<head>...]\\n\"\n+\"  --all and explicit <head> specification are mutually exclusive.\";\n static const char *exec = \"git-receive-pack\";\n static int send_all = 0;\n static int force_update = 0;\n@@ -214,7 +215,7 @@ static int send_pack(int in, int out, in\n \t/*\n \t * See if we have any refs that the other end didn't have\n \t */\n-\tif (nr_match) {\n+\tif (nr_match || send_all) {\n \t\tlocal_ref_nr_match = nr_match;\n \t\tlocal_ref_match = match;\n \t\tlocal_ref_list = ref_list;\n@@ -281,6 +282,8 @@ int main(int argc, char **argv)\n \t}\n \tif (!dest)\n \t\tusage(send_pack_usage);\n+\tif (heads && send_all)\n+\t\tusage(send_pack_usage);\n \tpid = git_connect(fd, dest, exec);\n \tif (pid < 0)\n \t\treturn 1;\n\n\n   \n"},{"id":"6656","messageId":"Pine.LNX.4.58.0507302257000.29650@g5.osdl.org","threadId":"1374","inReplyTo":"7v1x5fwmpk.fsf@assigned-by-dhcp.cox.net","subject":"Re: send-pack question.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-31T06:02:57Z","receivedAt":"2005-07-31T06:02:57Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 30 Jul 2005, Junio C Hamano wrote:\n> \n>  * Right now, \"send-pack --all\" into an empty repository does\n>    not do anything, but \"send-pack --all master\" into an empty\n>    repository pushes all local heads.  This is because we do not\n>    check \"send_all\" when deciding if we want to call try_match\n>    on local references.  I am assuming this is an oversight; am\n>    I correct?  If so, does the attached patch look OK?\n\nYeah, that sounds like me just not having taken my 'meds. The patch looks \nfine.\n\n>  * It appears to me that you can say \"send-pack net\", and\n>    depending on how the remote lists its refs, you can end up\n>    updating their refs/heads/net or refs/tags/net.\n\nYeh. I was wanting to sort the refs to make everything be totally \nrepeatable, but that was more of an urge than a real plan.\n\n>\t\t\t\t\t\t  More\n>    confusingly, you could say \"send-pack net net\" to update\n>    both.  More realistically, you could get confused with a\n>    remote that has refs/heads/jgarzik/net and\n>    refs/heads/dsmiller/net in this way.  I think it should\n>    detect, stop and warn about the ambiguity and require the\n>    user to be more explicit.  Am I reading the current code\n>    correctly?\n\nYes, warning on ambiguity sounds like a sound plan, and then you don't \nneed to sort.\n\nYou also probably to come up with a syntax for saying \"xyz is the local\nname, abc is the remote name\". That's needed for both the pulling and the \npushing side, but I didn't ever do it. \n\n>    I've always _hated_ the interface to path_match() which\n>    pretends to be just a boolean function but actually has a\n>    grave side effect, by the way.\n\nIt's \"interesting\" but useful. But I agree, we've had one bug already due\nto the interesting part.\n\nIf you do the ambiguity thing, you might mark them used some separate way, \nand maybe avoid that side effect (or rather - the side effect would still \nexist, but instead of removing the entry, it would just mark it as \n\"seen\", ie make it less drastic).\n\n\t\tLinus\n"}]}