{"thread":{"id":"6615","subject":"[PATCH] add --remote option to git-clone.","startedAt":"2007-02-01T22:01:22Z","lastAt":"2007-02-05T19:34:29Z","messageCount":20,"participants":["Michael S. Tsirkin","J. Bruce Fields","Shawn O. Pearce","Johannes Schindelin","Yann Dirson","Junio C Hamano","Jakub Narebski","Linus Torvalds"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"33294","messageId":"20070201220122.GF17617@mellanox.co.il","threadId":"6615","inReplyTo":null,"subject":"[PATCH] add --remote option to git-clone.","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2007-02-01T22:01:22Z","receivedAt":"2007-02-01T22:01:22Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"It is sometimes useful to track, and develop against, a single\ntopic branch from the remote repository.\nMake this easier to do by adding a flag to git-clone.\n\nSigned-off-by: Michael S. Tsirkin \n\n---\n\nWe have a repository with several long-lived topic branches.\n\nI'm often annoyed by the fact that when I clone from this repository,\nI get a copy of all topic branches and origin tracking master\nby default, when I actually might only want to work on a different\ntopic. And getting all extra branches is annoying on a slow connection.\n\nSo here's the patch to only get a single branch on clone.\nOther branches can be added later, on demand.\n\nJunio, what do you think?\nI would like very much for git to support this capability.\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex 707376f..f66a969 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -10,8 +10,8 @@ SYNOPSIS\n --------\n [verse]\n 'git-clone' [--template=] [-l [-s]] [-q] [-n] [--bare]\n-\t [-o ] [-u ] [--reference ]\n-\t [--depth=] []\n+\t [-o ] [-u ] [--remote ]\n+\t [--reference ] [--depth=] []\n \n DESCRIPTION\n -----------\n@@ -84,6 +84,10 @@ OPTIONS\n \tInstead of using the remote name 'origin' to keep track\n \tof the upstream repository, use instead.\n \n+--remote ::\n+\tWhen given, only the specified remote branch will be\n+\ttracked; if unset all remote branches are tracked.\n+\n --upload-pack ::\n -u ::\n \tWhen given, and the repository to clone from is handled\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 4ddfa77..b0fe7d1 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -14,7 +14,7 @@ die() {\n }\n \n usage() {\n-\tdie \"Usage: $0 [--template=] [--reference ] [--bare] [-l [-s]] [-q] [-u ] [--origin ] [--depth ] [-n] []\"\n+\tdie \"Usage: $0 [--template=] [--reference ] [--bare] [-l [-s]] [-q] [-u ] [--remote ] [--origin ] [--depth ] [-n] []\"\n }\n \n get_repo_base() {\n@@ -78,6 +78,8 @@ reference=\n origin=\n origin_override=\n use_separate_remote=t\n+remote_branch=\n+all_remote_branches=\"--all\"\n depth=\n while\n \tcase \"$#,$1\" in\n@@ -104,6 +106,10 @@ while\n \t\tshift; reference=\"$1\" ;;\n \t*,--reference=*)\n \t\treference=`expr \"z$1\" : 'z--reference=\\(.*\\)'` ;;\n+\t*,--remote)\n+\t\tremote_branch=\"$2\"\n+\t\tall_remote_branches=\n+\t \tshift ;;\n \t*,-o|*,--or|*,--ori|*,--orig|*,--origi|*,--origin)\n \t\tcase \"$2\" in\n \t\t'')\n@@ -227,7 +233,7 @@ yes,yes)\n \t echo \"$repo/objects\" >> \"$GIT_DIR/objects/info/alternates\"\n \t ;;\n \tesac\n-\tgit-ls-remote \"$repo\" >\"$GIT_DIR/CLONE_HEAD\" || exit 1\n+\tgit-ls-remote \"$repo\" $remote_branch >\"$GIT_DIR/CLONE_HEAD\" || exit 1\n \t;;\n *)\n \tcase \"$repo\" in\n@@ -261,7 +267,7 @@ yes,yes)\n \t\t done\n \t\t rm -f \"$GIT_DIR/TMP_ALT\"\n \t\tfi\n-\t\tgit-ls-remote \"$repo\" >\"$GIT_DIR/CLONE_HEAD\" || exit 1\n+\t\tgit-ls-remote \"$repo\" $remote_branch >\"$GIT_DIR/CLONE_HEAD\" || exit 1\n \t\t;;\n \thttps://*|http://*|ftp://*)\n \t\tcase \"$depth\" in\n@@ -277,8 +283,8 @@ yes,yes)\n \t\t;;\n \t*)\n \t\tcase \"$upload_pack\" in\n-\t\t'') git-fetch-pack --all -k $quiet $depth \"$repo\" ;;\n-\t\t*) git-fetch-pack --all -k $quiet \"$upload_pack\" $depth \"$repo\" ;;\n+\t\t'') git-fetch-pack $all_remote_branches -k $quiet $depth \"$repo\" $remote_branch;;\n+\t\t*) git-fetch-pack $all_remote_branches -k $quiet \"$upload_pack\" $depth \"$repo\" $remote_branch;;\n \t\tesac >\"$GIT_DIR/CLONE_HEAD\" ||\n \t\t\tdie \"fetch-pack from '$repo' failed.\"\n \t\t;;\n@@ -304,6 +310,9 @@ then\n \t\t\tcontinue ;;\n \t\tHEAD)\n \t\t\tdestname=\"REMOTE_HEAD\" ;;\n+\t\trefs/heads/$remote_branch)\n+\t\t\tgit-update-ref -m \"clone: from $repo\" \"REMOTE_HEAD\" \"$sha1\" \"\"\n+\t\t\tdestname=\"refs/$branch_top/${name#refs/heads/}\" ;;\n \t\trefs/heads/*)\n \t\t\tdestname=\"refs/$branch_top/${name#refs/heads/}\" ;;\n \t\trefs/tags/*)\n@@ -334,25 +343,32 @@ then\n \tesac\n \n \t# The name under $remote_top the remote HEAD seems to point at.\n-\thead_points_at=$(\n-\t\t(\n-\t\t\ttest -f \"$GIT_DIR/$remote_top/master\" && echo \"master\"\n-\t\t\tcd \"$GIT_DIR/$remote_top\" &&\n-\t\t\tfind . -type f -print | sed -e 's/^\\.\\///'\n-\t\t) | (\n-\t\tdone=f\n-\t\twhile read name\n-\t\tdo\n-\t\t\ttest t = $done && continue\n-\t\t\tbranch_tip=`cat \"$GIT_DIR/$remote_top/$name\"`\n-\t\t\tif test \"$head_sha1\" = \"$branch_tip\"\n-\t\t\tthen\n-\t\t\t\techo \"$name\"\n-\t\t\t\tdone=t\n-\t\t\tfi\n-\t\tdone\n+\tif\n+\t\ttest $remote_branch\n+\tthen\n+\t\thead_points_at=$remote_branch\n+\t\thead_sha1=`cat \"$GIT_DIR/REMOTE_HEAD\"`\n+\telse\n+\t\thead_points_at=$(\n+\t\t\t(\n+\t\t\t\ttest -f \"$GIT_DIR/$remote_top/master\" && echo \"master\"\n+\t\t\t\tcd \"$GIT_DIR/$remote_top\" &&\n+\t\t\t\tfind . -type f -print | sed -e 's/^\\.\\///'\n+\t\t\t) | (\n+\t\t\tdone=f\n+\t\t\twhile read name\n+\t\t\tdo\n+\t\t\t\ttest t = $done && continue\n+\t\t\t\tbranch_tip=`cat \"$GIT_DIR/$remote_top/$name\"`\n+\t\t\t\tif test \"$head_sha1\" = \"$branch_tip\"\n+\t\t\t\tthen\n+\t\t\t\t\techo \"$name\"\n+\t\t\t\t\tdone=t\n+\t\t\t\tfi\n+\t\t\tdone\n+\t\t\t)\n \t\t)\n-\t)\n+\tfi\n \n \t# Write out remote.$origin config, and update our \"$head_points_at\".\n \tcase \"$head_points_at\" in\n@@ -368,11 +384,18 @@ then\n \t\tgit-config remote.\"$origin\".url \"$repo\" &&\n \n \t\t# Set up the mappings to track the remote branches.\n-\t\tgit-config remote.\"$origin\".fetch \\\n-\t\t\t\"+refs/heads/*:$remote_top/*\" '^$' &&\n-\t\trm -f \"refs/remotes/$origin/HEAD\"\n-\t\tgit-symbolic-ref \"refs/remotes/$origin/HEAD\" \\\n-\t\t\t\"refs/remotes/$origin/$head_points_at\" &&\n+\t\t(if\n+\t\t\ttest $remote_branch\n+\t\tthen\n+\t\t\tgit-config remote.\"$origin\".fetch \\\n+\t\t\t\t\"+refs/heads/$remote_branch:$remote_top/$remote_branch\" '^$'\n+\t\telse\n+\t\t\tgit-config remote.\"$origin\".fetch \\\n+\t\t\t\t\"+refs/heads/*:$remote_top/*\" '^$' &&\n+\t\t\trm -f \"refs/remotes/$origin/HEAD\"\n+\t\t\tgit-symbolic-ref \"refs/remotes/$origin/HEAD\" \\\n+\t\t\t\t\"refs/remotes/$origin/$head_points_at\"\n+\t\tfi)\n \n \t\tgit-config branch.\"$head_points_at\".remote \"$origin\" &&\n \t\tgit-config branch.\"$head_points_at\".merge \"refs/heads/$head_points_at\"\n\n-- \nMST\n"},{"id":"33295","messageId":"20070201220657.GB19271@fieldses.org","threadId":"6615","inReplyTo":"20070201220122.GF17617@mellanox.co.il","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-02-01T22:06:57Z","receivedAt":"2007-02-01T22:06:57Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Fri, Feb 02, 2007 at 12:01:22AM +0200, Michael S. Tsirkin wrote:\n> I'm often annoyed by the fact that when I clone from this repository,\n> I get a copy of all topic branches and origin tracking master\n> by default, when I actually might only want to work on a different\n> topic. And getting all extra branches is annoying on a slow connection.\n\nCan you quantify \"annoying\"?\n\nNot a challenge, I'm just curious--I would've thought that, for most\nprojects, even with long-lived topic branches, it wouldn't be that\nexpensive to get a second branch once you'd gotten one.\n\n--b.\n"},{"id":"33297","messageId":"20070201221439.GC19057@spearce.org","threadId":"6615","inReplyTo":"20070201220657.GB19271@fieldses.org","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-01T22:14:39Z","receivedAt":"2007-02-01T22:14:39Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"J. Bruce Fields\" wrote:\n> On Fri, Feb 02, 2007 at 12:01:22AM +0200, Michael S. Tsirkin wrote:\n> > I'm often annoyed by the fact that when I clone from this repository,\n> > I get a copy of all topic branches and origin tracking master\n> > by default, when I actually might only want to work on a different\n> > topic. And getting all extra branches is annoying on a slow connection.\n> \n> Can you quantify \"annoying\"?\n> \n> Not a challenge, I'm just curious--I would've thought that, for most\n> projects, even with long-lived topic branches, it wouldn't be that\n> expensive to get a second branch once you'd gotten one.\n\nNot true; I work on projects like that and some of the branches\nare several MiB of additional objects beyond the other branches.\nIt can add up very, very fast.\n\nOver slow corporate VPN connections this is definately a problem.\nUsually the user only wants one branch *right now*. Getting another\n15 MiB of data for branches which they aren't interested in could\ntake another 5 minutes. If they do need those, they could always\nfetch the additional branches later, or do it from the office where\nthe network doesn't suck.\n\n-- \nShawn.\n"},{"id":"33304","messageId":"20070201230100.GL17617@mellanox.co.il","threadId":"6615","inReplyTo":"20070201220657.GB19271@fieldses.org","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2007-02-01T23:01:00Z","receivedAt":"2007-02-01T23:01:00Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting J. Bruce Fields :\n> Subject: Re: [PATCH] add --remote option to git-clone.\n> \n> On Fri, Feb 02, 2007 at 12:01:22AM +0200, Michael S. Tsirkin wrote:\n> > I'm often annoyed by the fact that when I clone from this repository,\n> > I get a copy of all topic branches and origin tracking master\n> > by default, when I actually might only want to work on a different\n> > topic. And getting all extra branches is annoying on a slow connection.\n> \n> Can you quantify \"annoying\"?\n> \n> Not a challenge, I'm just curious--I would've thought that, for most\n> projects, even with long-lived topic branches, it wouldn't be that\n> expensive to get a second branch once you'd gotten one.\n\nShawn already answered that, I concur.\n\n-- \nMST\n"},{"id":"33310","messageId":"Pine.LNX.4.63.0702020028540.18776@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6615","inReplyTo":"20070201220122.GF17617@mellanox.co.il","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-01T23:29:37Z","receivedAt":"2007-02-01T23:29:37Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nwould this option not be better named \"--branch\"? Of course, you'd have to \nsupport this, too:\n\n\t$ git clone --branch topic1 --branch topic2 git://...\n\nCiao,\nDscho\n"},{"id":"33311","messageId":"20070201233109.GA19446@spearce.org","threadId":"6615","inReplyTo":"Pine.LNX.4.63.0702020028540.18776@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-01T23:31:09Z","receivedAt":"2007-02-01T23:31:09Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> would this option not be better named \"--branch\"? Of course, you'd have to \n> support this, too:\n> \n> \t$ git clone --branch topic1 --branch topic2 git://...\n\nYes, --branch sounds better here.\n\n-- \nShawn.\n"},{"id":"33312","messageId":"20070201234246.GD5362@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6615","inReplyTo":"20070201220657.GB19271@fieldses.org","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-02-01T23:42:46Z","receivedAt":"2007-02-01T23:42:46Z","isPatch":true,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Thu, Feb 01, 2007 at 05:06:57PM -0500, J. Bruce Fields wrote:\n> On Fri, Feb 02, 2007 at 12:01:22AM +0200, Michael S. Tsirkin wrote:\n> > I'm often annoyed by the fact that when I clone from this repository,\n> > I get a copy of all topic branches and origin tracking master\n> > by default, when I actually might only want to work on a different\n> > topic. And getting all extra branches is annoying on a slow connection.\n> \n> Can you quantify \"annoying\"?\n> \n> Not a challenge, I'm just curious--I would've thought that, for most\n> projects, even with long-lived topic branches, it wouldn't be that\n> expensive to get a second branch once you'd gotten one.\n\nRegardless of the extra branches, it is also annoying to have the\nmaster branch in the clone branched off the HEAD of the parent repo.\nEspecially when you intend to fork an stgit stack off the non-HEAD\nbranch - it will be a pleasure to make \"stg clone\" to take advantage\nof this new feature :)\n\nThis is also a feature which is available in cogito since ages\n(cg-clone URL#branch), and not having it in plain git is an annoyance.\n\nBest regards,\n-- \nYann.\n"},{"id":"33313","messageId":"20070201234706.GP17617@mellanox.co.il","threadId":"6615","inReplyTo":"Pine.LNX.4.63.0702020028540.18776@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2007-02-01T23:47:06Z","receivedAt":"2007-02-01T23:47:06Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Johannes Schindelin :\n> Subject: Re: [PATCH] add --remote option to git-clone.\n> \n> Hi,\n> \n> would this option not be better named \"--branch\"?\n\nOK\n\n> Of course, you'd have to \n> support this, too:\n> \n> \t$ git clone --branch topic1 --branch topic2 git://...\n\nWhy is this useful? and which branch to check out?\nOne can always get more branches later, is my approach.\n\n-- \nMST\n"},{"id":"33319","messageId":"Pine.LNX.4.63.0702020050190.18870@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6615","inReplyTo":"20070201234706.GP17617@mellanox.co.il","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-01T23:53:14Z","receivedAt":"2007-02-01T23:53:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 2 Feb 2007, Michael S. Tsirkin wrote:\n\n> > Quoting Johannes Schindelin :\n> > Subject: Re: [PATCH] add --remote option to git-clone.\n> > \n> > Of course, you'd have to \n> > support this, too:\n> > \n> > \t$ git clone --branch topic1 --branch topic2 git://...\n> \n> Why is this useful?\n\nFor the same reasons it might be useful to track _all_ branches.\n\n> and which branch to check out?\n\nI'd say the first, but that's just my opinion.\n\n> One can always get more branches later, is my approach.\n\nYes. But in the same vein, one can add _one_ branch to an empty repo \neither. So, with your reasoning, your patch wouldn't be needed to begin \nwith.\n\nBut I find it useful. Even the version where you are not limited to one \nbranch.\n\nCiao,\nDscho\n"},{"id":"33325","messageId":"7vmz3xmju9.fsf@assigned-by-dhcp.cox.net","threadId":"6615","inReplyTo":"Pine.LNX.4.63.0702020050190.18870@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-02T01:25:34Z","receivedAt":"2007-02-02T01:25:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Fri, 2 Feb 2007, Michael S. Tsirkin wrote:\n> ...\n>> One can always get more branches later, is my approach.\n>\n> Yes. But in the same vein, one can add _one_ branch to an empty repo \n> either. So, with your reasoning, your patch wouldn't be needed to begin \n> with.\n\nIndeed.\n\n> But I find it useful. Even the version where you are not limited to one \n> branch.\n\nI am not against the general idea of tracking a subset of\nbranches, but issues include:\n\n [1] tracking multiple (but not all) branches, as you pointed out,\n\n [2] how this should interact with later fetches from the same\n remote.\n\n [3] allowing similar \"track these branches from a new remote\n from now on\" in an already initialized repository.\n\nPerhaps by specifying the --branch parameter in an wildcard\nfashion, remote.*.fetch can be initialized to that wildcard and\nlater new branches that match the wildcard pattern ca be fetched\n(which is a strawman solution for [1] and [2]). I suspect [3]\nbelongs to what \"git remote\" should allow you to do, but in that\ncase maybe \"git init-db ; git remote *that-new-command*\" would\nbe a single uniform way to solve all of the above?\n\nI personally feel this is post 1.5.0 material.\n"},{"id":"33370","messageId":"Pine.LNX.4.63.0702021146440.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6615","inReplyTo":"7vmz3xmju9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-02T10:48:10Z","receivedAt":"2007-02-02T10:48:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 1 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Fri, 2 Feb 2007, Michael S. Tsirkin wrote:\n> > ...\n> >> One can always get more branches later, is my approach.\n> >\n> > Yes. But in the same vein, one can add _one_ branch to an empty repo \n> > either. So, with your reasoning, your patch wouldn't be needed to begin \n> > with.\n> \n> Indeed.\n> \n> > But I find it useful. Even the version where you are not limited to one \n> > branch.\n> \n> I am not against the general idea of tracking a subset of\n> branches, but issues include:\n>\n> [explains why git-remote is a better place for this]\n\nSeeing your patch to git-remote, it feels more natural, too. Especially \nsince that (or which? :-D) does not give the term \"clone\" a \nMicrosoft'esque completely new meaning.\n\nCiao,\nDscho\n"},{"id":"33426","messageId":"7vmz3wdjxu.fsf@assigned-by-dhcp.cox.net","threadId":"6615","inReplyTo":"Pine.LNX.4.63.0702021146440.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-03T03:00:29Z","receivedAt":"2007-02-03T03:00:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Thu, 1 Feb 2007, Junio C Hamano wrote:\n> ...\n>> I am not against the general idea of tracking a subset of\n>> branches, but issues include:\n>>\n>> [explains why git-remote is a better place for this]\n>\n> Seeing your patch to git-remote, it feels more natural, too. Especially \n> since that (or which? :-D) does not give the term \"clone\" a \n> Microsoft'esque completely new meaning.\n\nI did not find anything MS'esque in what MST did in his patch,\nthough. I think it is a reasonable thing to ask for from a\nclone. For example, if you are coming from CVS or have used\nCogito, cloning a single branch is not an unusual operation at\nall.\n\nThe real point of my 'remote add -f -t -m' patch is that I think\nwe are much better off to do it in a bottom up way, by having a\ntool that can be used in any repository first. Then we could\neven rewrite 'git clone' along these lines:\n\n\t#/bin/sh\n\ttrack=\"*\" ;# command line parameter to override...\n\t... decide what $name to use ...\n\tmkdir \"$name\"\n\tcd \"$name\"\n\tgit init-db\n git remote add -f -t \"$track\" origin $url\n\tgit branch -f master remotes/origin/master\n\nOf course you would need to deal with -n, --bare and stuff, but\nthat is a minor detail.\n\nWhile I am talking about post 1.5.0 git-clone changes, one thing\nI've always hated about git-clone is that the cloner always has\nto guess where the HEAD pointer at the other side points at.\nThis comes from a shortcoming in the fetch-pack protocol (it\nsimply does not tell). A stupid consequence of this is that\ncloning over dumb protocols also have to guess, although they\nare _capable_ of letting the cloner know this information.\n\nI think the logic to decide where to point remotes/$origin/HEAD\nto should be moved to \"git-remote add -m\" when we eventually\nrewrite \"git-clone\" to use \"git-remote add -f\". And while we\nwould do so, we can make a trivial extension to fetch-pack\nprotocol to carry the HEAD symref information. All will be\ngood once that happens.\n"},{"id":"33437","messageId":"eq1j8i$rtv$1@sea.gmane.org","threadId":"6615","inReplyTo":"7vmz3wdjxu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-03T09:06:44Z","receivedAt":"2007-02-03T09:06:44Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n>> On Thu, 1 Feb 2007, Junio C Hamano wrote:\n>> ...\n>>> I am not against the general idea of tracking a subset of\n>>> branches, but issues include:\n>>>\n>>> [explains why git-remote is a better place for this]\n>>\n>> Seeing your patch to git-remote, it feels more natural, too. Especially \n>> since that (or which? :-D) does not give the term \"clone\" a \n>> Microsoft'esque completely new meaning.\n> \n> I did not find anything MS'esque in what MST did in his patch,\n> though. I think it is a reasonable thing to ask for from a\n> clone. For example, if you are coming from CVS or have used\n> Cogito, cloning a single branch is not an unusual operation at\n> all.\n\nBut when we clone whole repository we could have download whole\nobject database of cloned repo as-is (perhaps packing loose objects\nin smart/git-aware transports).\n\nBy the way, there was discussed idea about marking pu-like branches\nas being rewound (non-fast forwarding) in the config file, and somehow\ntransferring this information for git-clone for it to have '+' for\nsome refspecs. What happened to that idea? Was it abandoned because\nreflogs are now enabled by default, are protected from pruning, and\nit is easy to recover from accidental non-fast forward fetch which\nshouldn't be?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33439","messageId":"7v64aj7frr.fsf@assigned-by-dhcp.cox.net","threadId":"6615","inReplyTo":"eq1j8i$rtv$1@sea.gmane.org","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-03T09:27:04Z","receivedAt":"2007-02-03T09:27:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n>> I did not find anything MS'esque in what MST did in his patch,\n>> though. I think it is a reasonable thing to ask for from a\n>> clone. For example, if you are coming from CVS or have used\n>> Cogito, cloning a single branch is not an unusual operation at\n>> all.\n>\n> But when we clone whole repository we could have download whole\n> object database of cloned repo as-is (perhaps packing loose objects\n> in smart/git-aware transports).\n\nI think your point is if you have branches A and B, cloning A+B\nas a whole is a lot less expensive than cloning A and then B\nseparately. While that is true, I do not think that reasoning\nwould apply to somebody, especially behind a slow link, who is\nonly interested in A. She does not want to pay the cost of A+B,\nwhen she only wants A, even if A+B is much less expensive than\ntwice the cost of getting A.\n\nAlso, if she later gets interested in B, git fetch will make the\n\"what's common\" optimization. It won't be like cloning A and\nthen fetching B into the same repository later would be twice as\nexpensive compared to the case where you start from a clone as a\nwhole. The overall transfer cost would probably be comparable.\n\n> By the way, there was discussed idea about marking pu-like branches\n> as being rewound (non-fast forwarding) in the config file, and somehow\n> transferring this information for git-clone for it to have '+' for\n> some refspecs. What happened to that idea? Was it abandoned...\n\nWell, I would not call some idle talk without a concrete design\n(preferably with a proof-of-concept code, but that is not an\nabsolute requirement) \"idea\". Something that did not even start\ncannot get abandoned ;-).\n\nI thought that it would not hurt to have something like that,\nbut because in 1.5.0 \"git clone\" creates fetch configuration of\n'forcing' kind by default, I do not think it makes that much of\na difference.\n"},{"id":"33626","messageId":"Pine.LNX.4.63.0702051245050.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6615","inReplyTo":"7vmz3wdjxu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-05T11:51:32Z","receivedAt":"2007-02-05T11:51:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 2 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Thu, 1 Feb 2007, Junio C Hamano wrote:\n> > ...\n> >> I am not against the general idea of tracking a subset of\n> >> branches, but issues include:\n> >>\n> >> [explains why git-remote is a better place for this]\n> >\n> > Seeing your patch to git-remote, it feels more natural, too. \n> > Especially since that (or which? :-D) does not give the term \"clone\" a \n> > Microsoft'esque completely new meaning.\n> \n> I did not find anything MS'esque in what MST did in his patch, though. \n> I think it is a reasonable thing to ask for from a clone. For example, \n> if you are coming from CVS or have used Cogito, cloning a single branch \n> is not an unusual operation at all.\n\nOh? Well, to me, \"clone\" meant something like the genetics thing, i.e. get \na copy of the repository. Since a \"branch\" is not the complete repository, \nbut only part of it, I would have expected \"engraft\" instead of \"clone\" \nthere.\n\nBut I can learn! So (post-1.5.0, maybe?) I'd be perfectly d'accord with \nsomething like this\n\n\tgit clone git://.../git.git#html\n\nto mean \"just fetch the branch html, and check it out\".\n\n> The real point of my 'remote add -f -t -m' patch is that I think we are \n> much better off to do it in a bottom up way, by having a tool that can \n> be used in any repository first. Then we could even rewrite 'git clone' \n> along these lines:\n> \n> \t#/bin/sh\n> \ttrack=\"*\" ;# command line parameter to override...\n> \t... decide what $name to use ...\n> \tmkdir \"$name\"\n> \tcd \"$name\"\n> \tgit init-db\n> git remote add -f -t \"$track\" origin $url\n> \tgit branch -f master remotes/origin/master\n> \n> Of course you would need to deal with -n, --bare and stuff, but\n> that is a minor detail.\n\nYeah, that makes sense.\n\n> While I am talking about post 1.5.0 git-clone changes, one thing I've \n> always hated about git-clone is that the cloner always has to guess \n> where the HEAD pointer at the other side points at. This comes from a \n> shortcoming in the fetch-pack protocol (it simply does not tell). A \n> stupid consequence of this is that cloning over dumb protocols also have \n> to guess, although they are _capable_ of letting the cloner know this \n> information.\n> \n> I think the logic to decide where to point remotes/$origin/HEAD to \n> should be moved to \"git-remote add -m\" when we eventually rewrite \n> \"git-clone\" to use \"git-remote add -f\". And while we would do so, we \n> can make a trivial extension to fetch-pack protocol to carry the HEAD \n> symref information. All will be good once that happens.\n\nWould you like this as a multi_ack-like extension?\n\nBut then how to teach the dumb protocols in a backwards-compatible \nfashion?\n\nCiao,\nDscho\n"},{"id":"33644","messageId":"7vmz3smqpp.fsf@assigned-by-dhcp.cox.net","threadId":"6615","inReplyTo":"Pine.LNX.4.63.0702051245050.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-05T17:58:26Z","receivedAt":"2007-02-05T17:58:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Oh? Well, to me, \"clone\" meant something like the genetics thing, i.e. get \n> a copy of the repository. Since a \"branch\" is not the complete repository, \n> but only part of it, I would have expected \"engraft\" instead of \"clone\" \n> there.\n>\n> But I can learn! So (post-1.5.0, maybe?) I'd be perfectly d'accord with \n> something like this\n>\n> \tgit clone git://.../git.git#html\n>\n> to mean \"just fetch the branch html, and check it out\".\n\nI agree that the word \"clone\" to me sounds like \"copy the whole\nrepo\", so a single branch cloning feels it is something\ndifferent from \"clone\", but I do not think it means wholeness\nmust be the only mode of operation.\n\nExcept that I do not particularly think the URL fragment\nnotation is such a \"cool\" syntax.\n\n>> I think the logic to decide where to point remotes/$origin/HEAD to \n>> should be moved to \"git-remote add -m\" when we eventually rewrite \n>> \"git-clone\" to use \"git-remote add -f\". And while we would do so, we \n>> can make a trivial extension to fetch-pack protocol to carry the HEAD \n>> symref information. All will be good once that happens.\n>\n> Would you like this as a multi_ack-like extension?\n>\n> But then how to teach the dumb protocols in a backwards-compatible \n> fashion?\n\nI am not talking about enhancing ls-remote output nor info/refs\nfile format. I do not think we need to do anything special to\nsupport it in backwards compatible way.\n\nLook at what dumb protocols do in git-clone. http already knows\nwhere HEAD points at when it fetches HEAD with curl. I do not\nparticularly care about rsync, but I suspect it can be handled\nthe same way.\n"},{"id":"33647","messageId":"Pine.LNX.4.64.0702051014040.8424@woody.linux-foundation.org","threadId":"6615","inReplyTo":"7vmz3smqpp.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-05T18:43:19Z","receivedAt":"2007-02-05T18:43:19Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 5 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> >\n> > \tgit clone git://.../git.git#html\n> >\n> > to mean \"just fetch the branch html, and check it out\".\n> \n> Except that I do not particularly think the URL fragment\n> notation is such a \"cool\" syntax.\n\nI think the cogito '#' syntax is braindead.\n\nMuch better to use native git syntax, which is to just list the branch \nseparately. Why? Not only is it the way we do things for pull and friends, \nit's also what allows us to specify *multiple* branches.\n\nSo I would personally welcome a \"clone just a particular branch\", but in \nthat case I'd like it to be able to say more than one too..\n\n(In general, even if I clone _everything_, I'd also like to perhaps set \nthe default 'master' branch to track something else than what I'm cloning \nfrom. In fact, I think I'd generally prefer cloning everything, but \nsometimes I'd like to say \"I'm going to track the upstreams branch xyzzy \nrather than their default branch\").\n\nI realize that the\n\n\tgit clone []\n\nmeans that we can't have the same syntax as \"git pull\" (which doesn't take \nthe part), but that doesn't make the \"#branch\" syntax any better.\n\nSo I much prefer the\n\n\tgit clone [--default branch] [--branch x]* [\n\nkind of syntax.\n\n\t\t\tLinus\n"},{"id":"33648","messageId":"20070205184814.GD15775@mellanox.co.il","threadId":"6615","inReplyTo":"7vmz3smqpp.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2007-02-05T18:48:14Z","receivedAt":"2007-02-05T18:48:14Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Junio C Hamano writes:\n> > Johannes Schindelin writes:\n> > \tgit clone git://.../git.git#html\n> >\n> > to mean \"just fetch the branch html, and check it out\".\n>\n> Except that I do not particularly think the URL fragment\n> notation is such a \"cool\" syntax.\n\nOK, but I think it would be very good I think to have *some* URL-like syntax for\ngit-fetch etc - people are used to copying URLs out of mail (lots of MUAs even\nhighlight these nicely) so I often see that current syntax confuses\npeople: they seem to lose the branch and fetch/pull the wrong one.\n\n\n-- \nMST\n"},{"id":"33649","messageId":"20070205185541.GA16598@mellanox.co.il","threadId":"6615","inReplyTo":"Pine.LNX.4.64.0702051014040.8424@woody.linux-foundation.org","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2007-02-05T18:55:41Z","receivedAt":"2007-02-05T18:55:41Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> (In general, even if I clone _everything_, I'd also like to perhaps set \n> the default 'master' branch to track something else than what I'm cloning \n> from. In fact, I think I'd generally prefer cloning everything, but \n> sometimes I'd like to say \"I'm going to track the upstreams branch xyzzy \n> rather than their default branch\").\n> \n> I realize that the\n> \n> \tgit clone []\n> \n> means that we can't have the same syntax as \"git pull\" (which doesn't take \n> the part), but that doesn't make the \"#branch\" syntax any better.\n> \n> So I much prefer the\n> \n> \tgit clone [--default branch] [--branch x]* [\n> \n> kind of syntax.\n\nTwo questions:\n- I understand --branch is too large for 1.5.0, but maybe this --default isn't?\n- Or, maybe we can have a flag to avoid creating the master branch at all?\n User can combine this with -n, then check which branches exist with \"git branch -r\"\n and create the branch himself.\n\n-- \nMST\n"},{"id":"33652","messageId":"20070205193429.GA8409@spearce.org","threadId":"6615","inReplyTo":"Pine.LNX.4.64.0702051014040.8424@woody.linux-foundation.org","subject":"Re: [PATCH] add --remote option to git-clone.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-05T19:34:29Z","receivedAt":"2007-02-05T19:34:29Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> I realize that the\n> \n> \tgit clone []\n> \n> means that we can't have the same syntax as \"git pull\" (which doesn't take \n> the part), but that doesn't make the \"#branch\" syntax any better.\n> \n> So I much prefer the\n> \n> \tgit clone [--default branch] [--branch x]* []\n> \n> kind of syntax.\n\nUgh. That means the bash completion cannot (easily) do something\nfancy, like tab completion of branch names within . Yea,\nits not fast on slow links, but it beats typing out an ugly branch\nname. :-)\n\n-- \nShawn.\n"}]}