{"thread":{"id":"21813","subject":"[PATCH v2] Add --track option to git clone","startedAt":"2009-12-01T22:51:03Z","lastAt":"2009-12-03T05:31:46Z","messageCount":13,"participants":["David Soria Parra","Sean Estabrooks","Nanako Shiraishi","Jeff King","Junio C Hamano","Björn Steinbrink"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"128932","messageId":"1259707865-6561-1-git-send-email-sn_@gmx.net","threadId":"21813","inReplyTo":null,"subject":"[PATCH v2] Add --track option to git clone","fromName":"David Soria Parra","fromEmail":"sn_@gmx.net","sentAt":"2009-12-01T22:51:03Z","receivedAt":"2009-12-01T22:51:03Z","isPatch":true,"sender":{"key":"sn_@gmx.net","avatar":"https://gravatar.com/avatar/b1075ecdd33ea094cbc23798fe8b95c73ec1ccf7bb213ac8260c719e2dd97b55?d=mp&s=160"},"body":"Update: \n + added a test\n\nThe following series adds a --track option to git clone. If the --track option\nis specified only the given remote branch will be received and checked out.\n\nIt tries to make the following usecase possible:\nImagine you are working on a project that has 1.x and a 2.x branch. The project\nitself requires a complex setup (webserver, configuration files, etc). Setting up\n1.x and 2.x branch requires a lot of work, but a developer needs to maintain both.\nHe'll use the --track option to clone the 2.x branch into a directory and does the same\nwith the 1.x branch, where he setup the project. He can use locally separate repositories\nwhile still being able to push to just one remote repository.\n\nI'm aware that it's not possible to give more than one --track option. Implementing\nthe possibility to specify multiple --track option would certainly a good improvment\nlater, but would also require a lot more work as far as I understand the clone code.\n\nBeing able to specify just one --track option is a compromise of doing a small change\nand implementing this feature.\n"},{"id":"128934","messageId":"1259707865-6561-2-git-send-email-sn_@gmx.net","threadId":"21813","inReplyTo":"1259707865-6561-1-git-send-email-sn_@gmx.net","subject":"[PATCH v2 1/2] Teach clone to clone just one remote branch using --track","fromName":"David Soria Parra","fromEmail":"sn_@gmx.net","sentAt":"2009-12-01T22:51:04Z","receivedAt":"2009-12-01T22:51:04Z","isPatch":true,"sender":{"key":"sn_@gmx.net","avatar":"https://gravatar.com/avatar/b1075ecdd33ea094cbc23798fe8b95c73ec1ccf7bb213ac8260c719e2dd97b55?d=mp&s=160"},"body":"From: David Soria Parra \n\nAdd a --track option that can be used to clone just the\ngiven branch from the remote and nothing else. This is done\nby setting the remote..fetch option before cloning.\nThis option cannot be used together with --mirror.\nFor example using\n\n git clone --track next git://git.kernel.org/pub/scm/git/git.git\n\nwill just clone the next branch from the git.git repository.\n\nThe option is called --track to ensure clean wording with\n'git remote add --track'.\n\nSigned-off-by: David Soria Parra \n---\n builtin-clone.c | 12 +++++++++++-\n t/t5708-clone-track.sh | 43 +++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 54 insertions(+), 1 deletions(-)\n create mode 100755 t/t5708-clone-track.sh\n\ndiff --git a/builtin-clone.c b/builtin-clone.c\nindex 5df8b0f..bc335ee 100644\n--- a/builtin-clone.c\n+++ b/builtin-clone.c\n@@ -43,6 +43,7 @@ static char *option_template, *option_reference, *option_depth;\n static char *option_origin = NULL;\n static char *option_branch = NULL;\n static char *option_upload_pack = \"git-upload-pack\";\n+static char *option_track = NULL;\n static int option_verbose;\n \n static struct option builtin_clone_options[] = {\n@@ -76,6 +77,8 @@ static struct option builtin_clone_options[] = {\n \t\t \"path to git-upload-pack on the remote\"),\n \tOPT_STRING(0, \"depth\", &option_depth, \"depth\",\n \t\t \"create a shallow clone of that depth\"),\n+\tOPT_STRING('t', \"track\", &option_track, \"branch\",\n+\t\t\t\"remote branche to track\"),\n \n \tOPT_END()\n };\n@@ -483,7 +486,14 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\tstrbuf_addf(&branch_top, \"refs/remotes/%s/\", option_origin);\n \t}\n \n-\tstrbuf_addf(&value, \"+%s*:%s*\", src_ref_prefix, branch_top.buf);\n+\tif (option_track) {\n+\t\tif (option_mirror)\n+\t\t\treturn error(\"Cannot use --track together with --mirror\");\n+\t\tstrbuf_addf(&value, \"+%s%s:%s%s\", src_ref_prefix, option_track, branch_top.buf, option_track);\n+\t\toption_branch = option_track;\n+\t} else {\n+\t\tstrbuf_addf(&value, \"+%s*:%s*\", src_ref_prefix, branch_top.buf);\n+\t}\n \n \tif (option_mirror || !option_bare) {\n \t\t/* Configure the remote */\ndiff --git a/t/t5708-clone-track.sh b/t/t5708-clone-track.sh\nnew file mode 100755\nindex 0000000..71b8461\n--- /dev/null\n+++ b/t/t5708-clone-track.sh\n@@ -0,0 +1,43 @@\n+#!/bin/sh\n+\n+test_description='clone --track option'\n+. ./test-lib.sh\n+\n+check_HEAD() {\n+\techo refs/heads/\"$1\" >expect &&\n+\tgit symbolic-ref HEAD >actual &&\n+\ttest_cmp expect actual\n+}\n+\n+check_file() {\n+\techo \"$1\" >expect &&\n+\ttest_cmp expect file\n+}\n+\n+test_expect_success 'setup' '\n+\tmkdir parent &&\n+\t(cd parent && git init &&\n+\t echo one >file && git add file && git commit -m one &&\n+\t git checkout -b two &&\n+\t echo two >file && git add file && git commit -m two &&\n+\t git checkout master)\n+'\n+\n+test_expect_success 'vanilla clone has both branches' '\n+\tgit clone parent clone &&\n+\t(cd clone &&\n+\tgit branch -r | grep master &&\n+\tgit branch -r | grep two\n+\t)\n+'\n+\n+test_expect_success 'clone -t chooses specified remote branch' '\n+\tgit clone -t two parent clone-two &&\n+\t(cd clone-two &&\n+\t!(git branch -r | grep master) &&\n+\tgit branch -r | grep two &&\n+\tcheck_HEAD two\n+\t)\n+'\n+\n+test_done\n-- \n1.6.6.rc0.268.g1c272\n"},{"id":"128933","messageId":"1259707865-6561-3-git-send-email-sn_@gmx.net","threadId":"21813","inReplyTo":"1259707865-6561-1-git-send-email-sn_@gmx.net","subject":"[PATCH v2 2/2] Documentation: Add --track option to the git clone manpage","fromName":"David Soria Parra","fromEmail":"sn_@gmx.net","sentAt":"2009-12-01T22:51:05Z","receivedAt":"2009-12-01T22:51:05Z","isPatch":true,"sender":{"key":"sn_@gmx.net","avatar":"https://gravatar.com/avatar/b1075ecdd33ea094cbc23798fe8b95c73ec1ccf7bb213ac8260c719e2dd97b55?d=mp&s=160"},"body":"From: David Soria Parra \n\nSigned-off-by: David Soria Parra \n---\n Documentation/git-clone.txt | 8 +++++++-\n 1 files changed, 7 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex 7ccd742..c2ab645 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -11,7 +11,7 @@ SYNOPSIS\n [verse]\n 'git clone' [--template=]\n \t [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]\n-\t [-o ] [-b ] [-u ] [--reference ]\n+\t [-o ] [-b ] [-t ] [-u ] [--reference ]\n \t [--depth ] [--recursive] [--] []\n \n DESCRIPTION\n@@ -135,6 +135,12 @@ objects from the source repository into a pack in the cloned repository.\n \tinstead. In a non-bare repository, this is the branch that will\n \tbe checked out.\n \n+--track ::\n+-t ::\n+\tInstead of cloning the complete remote repository, only the given\n+\tremote branch `` will be tracked and checked out.\n+\tThis implies --branch ``.\n+\n --upload-pack ::\n -u ::\n \tWhen given, and the repository to clone from is accessed\n-- \n1.6.6.rc0.268.g1c272\n"},{"id":"128962","messageId":"BLU0-SMTP487572F057CC9D30C837D7AE950@phx.gbl","threadId":"21813","inReplyTo":"1259707865-6561-1-git-send-email-sn_@gmx.net","subject":"Re: [PATCH v2] Add --track option to git clone","fromName":"Sean Estabrooks","fromEmail":"seanlkml@sympatico.ca","sentAt":"2009-12-02T02:08:25Z","receivedAt":"2009-12-02T02:08:25Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 1 Dec 2009 23:51:03 +0100\nDavid Soria Parra wrote:\n\n> The following series adds a --track option to git clone. If the --track option\n> is specified only the given remote branch will be received and checked out.\n\nIMHO, the term \"track\" is already overloaded in Git and this doesn't help make\nthings clearer.\n\n> It tries to make the following usecase possible:\n> Imagine you are working on a project that has 1.x and a 2.x branch. The project\n> itself requires a complex setup (webserver, configuration files, etc). Setting up\n> 1.x and 2.x branch requires a lot of work, but a developer needs to maintain both.\n> He'll use the --track option to clone the 2.x branch into a directory and does the same\n> with the 1.x branch, where he setup the project. He can use locally separate repositories\n> while still being able to push to just one remote repository.\n\nThis is already straightforward in Git without the limitation of tracking only\na single remote branch. What is the necessity of doing this via the clone command?\n\n $ git init myrepo\n $ cd myrepo\n $ git remote add -t branch1.x -f origin \n $ git checkout -t origin/branch1.x\n\nSean\n"},{"id":"128978","messageId":"slrnhhc58g.cpv.sn_@experimentalworks.net","threadId":"21813","inReplyTo":"BLU0-SMTP487572F057CC9D30C837D7AE950@phx.gbl","subject":"Re: [PATCH v2] Add --track option to git clone","fromName":"David Soria Parra","fromEmail":"sn_@gmx.net","sentAt":"2009-12-02T07:20:44Z","receivedAt":"2009-12-02T07:20:44Z","isPatch":true,"sender":{"key":"sn_@gmx.net","avatar":"https://gravatar.com/avatar/b1075ecdd33ea094cbc23798fe8b95c73ec1ccf7bb213ac8260c719e2dd97b55?d=mp&s=160"},"body":"On 2009-12-02, Sean Estabrooks wrote:\n>> It tries to make the following usecase possible:\n>> Imagine you are working on a project that has 1.x and a 2.x branch. The project\n>> itself requires a complex setup (webserver, configuration files, etc). Setting up\n>> 1.x and 2.x branch requires a lot of work, but a developer needs to maintain both.\n>> He'll use the --track option to clone the 2.x branch into a directory and does the same\n>> with the 1.x branch, where he setup the project. He can use locally separate repositories\n>> while still being able to push to just one remote repository.\n>\n> This is already straightforward in Git without the limitation of tracking only\n> a single remote branch. What is the necessity of doing this via the clone command?\n>\n> $ git init myrepo\n> $ cd myrepo\n> $ git remote add -t branch1.x -f origin \n> $ git checkout -t origin/branch1.x\nI'm aware that this is possible, but I want to have a shortcut for this as the users that I\nhelped with getting into git usually where confused about the point that you have to do it manually\nvia git init, so take the patch as a proposal to get more consistent interface for git clone.\n\ndavid\n"},{"id":"128991","messageId":"20091202192028.6117@nanako3.lavabit.com","threadId":"21813","inReplyTo":"1259707865-6561-1-git-send-email-sn_@gmx.net","subject":"Re: [PATCH v2] Add --track option to git clone","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-12-02T10:20:28Z","receivedAt":"2009-12-02T10:20:28Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting David Soria Parra writes:\n\n> I'm aware that it's not possible to give more than one --track\n> option. Implementing the possibility to specify multiple --track option\n> would certainly a good improvment later, but would also require a lot\n> more work as far as I understand the clone code.\n\nI'm sorry if I'm asking the obvious, but how can multiple --track \noptions be a useful future enhancement? If I understand your use \ncase correctly, it's useful when you want to work on only one \nbranch that isn't the default, and that is why you don't want to \nget data necessary for other branches. What does it mean to give \ntwo --track options? You will get one master branch that tracks\nboth versions, and \"git pull\" will merge both branches you track?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"128995","messageId":"slrnhhcgi8.cpv.sn_@experimentalworks.net","threadId":"21813","inReplyTo":"20091202192028.6117@nanako3.lavabit.com","subject":"Re: [PATCH v2] Add --track option to git clone","fromName":"David Soria Parra","fromEmail":"sn_@gmx.net","sentAt":"2009-12-02T10:33:41Z","receivedAt":"2009-12-02T10:33:41Z","isPatch":true,"sender":{"key":"sn_@gmx.net","avatar":"https://gravatar.com/avatar/b1075ecdd33ea094cbc23798fe8b95c73ec1ccf7bb213ac8260c719e2dd97b55?d=mp&s=160"},"body":"On 2009-12-02, Nanako Shiraishi wrote:\n> Quoting David Soria Parra writes:\n>\n>> I'm aware that it's not possible to give more than one --track\n>> option. Implementing the possibility to specify multiple --track option\n>> would certainly a good improvment later, but would also require a lot\n>> more work as far as I understand the clone code.\n>\n> I'm sorry if I'm asking the obvious, but how can multiple --track \n> options be a useful future enhancement? If I understand your use \n> case correctly, it's useful when you want to work on only one \n> branch that isn't the default, and that is why you don't want to \n> get data necessary for other branches. What does it mean to give \n> two --track options? You will get one master branch that tracks\n> both versions, and \"git pull\" will merge both branches you track?\n\nSimilar to git remote add --track it'll pull all branches specified by a --track\noption and checkout the first one or -o if given. For me personally it's\nnot an improvemen, because I just need to clone on branch, but as git remote add allows\nmultiple branches specified by --track I thought this might be an improvment.\n"},{"id":"129041","messageId":"20091202190807.GB30778@coredump.intra.peff.net","threadId":"21813","inReplyTo":"20091202192028.6117@nanako3.lavabit.com","subject":"Re: [PATCH v2] Add --track option to git clone","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-12-02T19:08:07Z","receivedAt":"2009-12-02T19:08:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 02, 2009 at 07:20:28PM +0900, Nanako Shiraishi wrote:\n\n> Quoting David Soria Parra writes:\n> \n> > I'm aware that it's not possible to give more than one --track\n> > option. Implementing the possibility to specify multiple --track option\n> > would certainly a good improvment later, but would also require a lot\n> > more work as far as I understand the clone code.\n> \n> I'm sorry if I'm asking the obvious, but how can multiple --track \n> options be a useful future enhancement? If I understand your use \n> case correctly, it's useful when you want to work on only one \n> branch that isn't the default, and that is why you don't want to \n> get data necessary for other branches. What does it mean to give \n> two --track options? You will get one master branch that tracks\n> both versions, and \"git pull\" will merge both branches you track?\n\nI would find something like this useful for cloning git.git, where I\nexplicitly fetch maint, master, next, and pu, but none of html, man, or\ntodo. This makes \"gitk --all\" much nicer to view.\n\nHowever, I don't think --track is the right term. There are really two\nthings happening here:\n\n 1. Setting the fetch refspec(s).\n\n 2. Choosing an initial branch to checkout.\n\nWe can already do (2) with \"-b\". But there is no way to do (1)\ncurrently. If we are going to implement (1), I don't see a reason to be\nrestrictive about it. We should really accept arbitrary refspecs, and\nthen provide a syntax on top of that for doing both (1) and (2)\ntogether. I am thinking something like:\n\n # most general case\n git clone -f 'refs/heads/subset/*:refs/remotes/origin/*' remote.git\n\n # expands to refs/heads/subset/*:refs/remotes/origin/*\n git clone -f 'refs/heads/subset/*' remote.git\n\n # expands to refs/heads/subset/*, which then expands as above\n git clone -f 'subset/*' remote.git\n\n # multiple -f should add multiple refspec lines\n git clone -f maint -f master -f next -f pu git.git\n\n # choose your favorite branch\n git clone -f maint -f master -f next -f pu -b next git.git\n\nAnd for convenience of the user, you would want a way to avoid repeating\nthe name of the \"I want to check this out\" branch. So either:\n\n 1. Add \"--track foo\" as a convenience wrapper for \"-f foo -b foo\".\n\n 2. If no \"-b\" is given, the first \"-f\" is assumed as \"-b\". So \"git\n clone -f foo\" becomes equivalent to David's --track.\n\nAnd of course the name \"-f\" (for --fetch, if you were wondering) is open\nto suggestion.\n\nWhat do you think?\n\n-Peff\n"},{"id":"129046","messageId":"slrnhhdfr1.d2h.sn_@experimentalworks.net","threadId":"21813","inReplyTo":"20091202190807.GB30778@coredump.intra.peff.net","subject":"Re: [PATCH v2] Add --track option to git clone","fromName":"David Soria Parra","fromEmail":"sn_@gmx.net","sentAt":"2009-12-02T19:27:27Z","receivedAt":"2009-12-02T19:27:27Z","isPatch":true,"sender":{"key":"sn_@gmx.net","avatar":"https://gravatar.com/avatar/b1075ecdd33ea094cbc23798fe8b95c73ec1ccf7bb213ac8260c719e2dd97b55?d=mp&s=160"},"body":"On 2009-12-02, Jeff King wrote:\n> 1. Add \"--track foo\" as a convenience wrapper for \"-f foo -b foo\".\n>\n> 2. If no \"-b\" is given, the first \"-f\" is assumed as \"-b\". So \"git\n> clone -f foo\" becomes equivalent to David's --track.\n>\n> And of course the name \"-f\" (for --fetch, if you were wondering) is open\n> to suggestion.\n>\n> What do you think?\n>\nThis approach is much better than my initial proposal. Sadly I won't have time\nto implement this, which is why I wrote the simplest working solution for me.\nFetch seems to reasonable. I can rewrite the patch to be able to use refspecs, but\nit would require additional refactoring to be able to specify multiple --fetch parameters.\n\nDavid\n"},{"id":"129066","messageId":"20091203060708.6117@nanako3.lavabit.com","threadId":"21813","inReplyTo":"20091202190807.GB30778@coredump.intra.peff.net","subject":"Re: [PATCH v2] Add --track option to git clone","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-12-02T21:07:08Z","receivedAt":"2009-12-02T21:07:08Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Jeff King \n\n> I would find something like this useful for cloning git.git, where I\n> explicitly fetch maint, master, next, and pu, but none of html, man, or\n> todo. This makes \"gitk --all\" much nicer to view.\n\nThank you for explaining. I now can understand why it can be useful.\n\n> # most general case\n> git clone -f 'refs/heads/subset/*:refs/remotes/origin/*' remote.git\n\nBecause this is only about branches and no other kinds of \nreferences, I think this is an overkill.\n\n> git clone -f 'subset/*' remote.git\n\nBut I think this is a good idea.\n\n> # multiple -f should add multiple refspec lines\n> git clone -f maint -f master -f next -f pu git.git\n>\n> # choose your favorite branch\n> git clone -f maint -f master -f next -f pu -b next git.git\n> ...\n> What do you think?\n\nI think your rule to make first branch given by -f the default \nfor -b is a good idea. But I'm not very happy with the example \nwith four -f. Can we probably write it like this?\n\n git clone -f maint,master,next,pu git.git\n\nIf it isn't a good idea to use comma, we can use colon to split \nthe list of branch names instead.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"129079","messageId":"20091202223728.GB9691@coredump.intra.peff.net","threadId":"21813","inReplyTo":"20091203060708.6117@nanako3.lavabit.com","subject":"Re: [PATCH v2] Add --track option to git clone","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-12-02T22:37:29Z","receivedAt":"2009-12-02T22:37:29Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 03, 2009 at 06:07:08AM +0900, Nanako Shiraishi wrote:\n\n> > # most general case\n> > git clone -f 'refs/heads/subset/*:refs/remotes/origin/*' remote.git\n> \n> Because this is only about branches and no other kinds of \n> references, I think this is an overkill.\n\nPerhaps. I'm not sure this has to be only about branches. You could do:\n\n git clone -f tags/v1.6.1 git.git\n\nthough I admit I don't really have a burning desire to do so. I just\nthink it will be simple to make it flexible (since you have to build\nsuch a refspec _anyway_), and there is no reason to restrict people who\nmight use it creatively.\n\nThe biggest argument against it would be that we are confusing the user\nby giving too much rope, but I don't think that is the case here. If\nyou just use branches, you need never know that the full refspec exists\n(just as some people use \"git fetch origin master\" without ever\nunderstanding how \"master\" can be replaced by a full refspec).\n\n> > git clone -f 'subset/*' remote.git\n> \n> But I think this is a good idea.\n\nOne question on this: does it fetch to \"refs/remotes/origin/subset/*\"\nor to \"refs/remotes/origin/*\"?\n\nI think the latter makes more sense (presumably you don't care that your\nbranches are in \"subset/\", since you by definition have asked for\nnothing outside of that namespace).\n\n> > # choose your favorite branch\n> > git clone -f maint -f master -f next -f pu -b next git.git\n> > ...\n> > What do you think?\n> \n> I think your rule to make first branch given by -f the default \n> for -b is a good idea. But I'm not very happy with the example \n> with four -f. Can we probably write it like this?\n> \n> git clone -f maint,master,next,pu git.git\n\nYeah, that is much nicer. I think \",\" is allowed in ref names, but I\nam tempted not to care here. It is not as if this is a low-level\nfeature, and most people will not be crazy enough to use commas in their\nbranch-names. IOW, you will get into trouble only if you have crazy\nnames _and_ you want to use this particular feature. If we wanted to be\ncomplete, we could provide a quoting mechanism, but that is perhaps\nexcessive.\n\n> If it isn't a good idea to use comma, we can use colon to split \n> the list of branch names instead.\n\nColon would work (though of course it would imply not allowing full\nrefspecs with \"-f\"). However, I actually find\n\n git clone -f maint:master:next:pu git.git\n\nto be a bit ugly and confusing.\n\n-Peff\n"},{"id":"129084","messageId":"7v1vjd9dz4.fsf@alter.siamese.dyndns.org","threadId":"21813","inReplyTo":"20091202223728.GB9691@coredump.intra.peff.net","subject":"Re: [PATCH v2] Add --track option to git clone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-02T23:02:23Z","receivedAt":"2009-12-02T23:02:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> git clone -f maint,master,next,pu git.git\n>\n> Yeah, that is much nicer. I think \",\" is allowed in ref names, but I\n> am tempted not to care here. It is not as if this is a low-level\n> feature, and most people will not be crazy enough to use commas in their\n> branch-names. IOW, you will get into trouble only if you have crazy\n> names _and_ you want to use this particular feature. If we wanted to be\n> complete, we could provide a quoting mechanism, but that is perhaps\n> excessive.\n\nYeah, I agree it is Ok not to support crazy people in this case. Not\nsupporting from the very beginning is quite different from _breaking_ them\n;-)\n"},{"id":"129103","messageId":"20091203053146.GA23215@atjola.homenet","threadId":"21813","inReplyTo":"20091202190807.GB30778@coredump.intra.peff.net","subject":"Re: [PATCH v2] Add --track option to git clone","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-03T05:31:46Z","receivedAt":"2009-12-03T05:31:46Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.02 14:08:07 -0500, Jeff King wrote:\n> And for convenience of the user, you would want a way to avoid repeating\n> the name of the \"I want to check this out\" branch. So either:\n> \n> 1. Add \"--track foo\" as a convenience wrapper for \"-f foo -b foo\".\n\nHm, we already have --track for \"remote add\", and that supports being\nsupplied multiple times, so I guess for clone, that should work too. But\nif track implies -b, having multiple --track seems rather weird. Which\nbranch head would be created? One for the first --track? Or the last\none? Or one for each? So I'd rather not make --track imply -b.\n\n> 2. If no \"-b\" is given, the first \"-f\" is assumed as \"-b\". So \"git\n> clone -f foo\" becomes equivalent to David's --track.\n\nWon't work if the first one is -f refs/heads/subst/*:refs/remotes/origin/*\n\n> And of course the name \"-f\" (for --fetch, if you were wondering) is open\n> to suggestion.\n> \n> What do you think?\n\nI'd prefer to see just --track for consistency with \"remote add\". That\ncould even learn to use globs, but allowing to specify the right side of\nthe refspec seems wrong given the option name, so it would be more\nlimited than your -f option.\n\nBjörn\n"}]}