{"thread":{"id":"22201","subject":"[PATCH] git push --track","startedAt":"2010-01-13T15:12:49Z","lastAt":"2010-01-15T18:54:49Z","messageCount":42,"participants":["Rudolf Polzer","Ilari Liusvaara","Matthieu Moy","Miles Bader","Johannes Schindelin","Tay Ray Chuan","Nanako Shiraishi","Jeff King","Martin Langhoff","Andreas Krey","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"131483","messageId":"op.u6g8jnixg402ra@nb-04","threadId":"22201","inReplyTo":null,"subject":"[PATCH] git push --track","fromName":"Rudolf Polzer","fromEmail":"divverent@alientrap.org","sentAt":"2010-01-13T15:12:49Z","receivedAt":"2010-01-13T15:12:49Z","isPatch":true,"sender":{"key":"divverent@alientrap.org","avatar":null},"body":"Hi,\n\nI'd like a feature to automatically \"transform\" a non-tracking local \nbranch into a tracking branch on push. A patch to do that is attached.\n\nUsage:\n\ngit branch mybranch\ngit checkout mybranch\n...\ngit push --track origin mybranch:mybranch\n\nwill not just perform the push, but also write a block\n\n[branch \"mybranch\"]\n remote = origin\n merge = refs/heads/mybranch\n\nto the git configuration so the branch becomes tracking.\n\nThis should be a simpler alternative to the otherwise usual procedure\n\ngit push origin mybranch:mybranch\ngit config branch.mybranch.remote origin\ngit config branch.mybranch.merge refs/heads/mybranch\n\nAre there any chances for this getting added to official git - or an \nalternate convenient way convert a local to a tracking branch?\n\nBest regards,\n\nRudolf\n\ndiff --git a/builtin-push.c b/builtin-push.c\nindex 28a26e7..8d68646 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -7,6 +7,7 @@\n #include \"builtin.h\"\n #include \"remote.h\"\n #include \"transport.h\"\n+#include \"branch.h\"\n #include \"parse-options.h\"\n \n static const char * const push_usage[] = {\n@@ -115,6 +116,33 @@ static int push_with_options(struct transport *transport, int flags)\n \t\tfprintf(stderr, \"Pushing to %s\\n\", transport->url);\n \terr = transport_push(transport, refspec_nr, refspec, flags,\n \t\t\t &nonfastforward);\n+\tif (err == 0 && flags & TRANSPORT_PUSH_TRACK)\n+\t{\n+\t\tstruct ref *remote_refs =\n+\t\t\ttransport->get_refs_list(transport, 1);\n+\t\tstruct ref *local_refs = get_local_heads();\n+\t\tint match_flags = 0;\n+\t\tif (flags & TRANSPORT_PUSH_ALL)\n+\t\t\tmatch_flags |= MATCH_REFS_ALL;\n+\t\tif (flags & TRANSPORT_PUSH_MIRROR)\n+\t\t\tmatch_flags |= MATCH_REFS_MIRROR;\n+\t\tif(!(flags & TRANSPORT_PUSH_DRY_RUN))\n+\t\tif(!match_refs(local_refs, &remote_refs, refspec_nr, refspec, match_flags))\n+\t\t{\n+\t\t\tstruct ref *next = remote_refs;\n+\t\t\twhile(next)\n+\t\t\t{\n+\t\t\t\tif(next->peer_ref && *next->peer_ref->name && *next->name && next->peer_ref->new_sha1 && !is_null_sha1(next->peer_ref->new_sha1))\n+\t\t\t\t{\n+\t\t\t\t\tif (!prefixcmp(next->peer_ref->name, \"refs/heads/\"))\n+\t\t\t\t\t{\n+\t\t\t\t\t\tinstall_branch_config(BRANCH_CONFIG_VERBOSE, next->peer_ref->name + 11, transport->remote->name, next->name);\n+\t\t\t\t\t}\n+\t\t\t\t}\n+\t\t\t\tnext = next->next;\n+\t\t\t}\n+\t\t}\n+\t}\n \tif (err != 0)\n \t\terror(\"failed to push some refs to '%s'\", transport->url);\n \n@@ -218,6 +246,8 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tOPT_BOOLEAN( 0 , \"thin\", &thin, \"use thin pack\"),\n \t\tOPT_STRING( 0 , \"receive-pack\", &receivepack, \"receive-pack\", \"receive pack program\"),\n \t\tOPT_STRING( 0 , \"exec\", &receivepack, \"receive-pack\", \"receive pack program\"),\n+\t\tOPT_BIT('t', \"track\", &flags, \"set up tracking mode (see git-pull(1))\",\n+\t\t\tTRANSPORT_PUSH_TRACK),\n \t\tOPT_END()\n \t};\n \ndiff --git a/transport.h b/transport.h\nindex 9e74406..8a9c776 100644\n--- a/transport.h\n+++ b/transport.h\n@@ -74,6 +74,7 @@ struct transport {\n #define TRANSPORT_PUSH_VERBOSE 16\n #define TRANSPORT_PUSH_PORCELAIN 32\n #define TRANSPORT_PUSH_QUIET 64\n+#define TRANSPORT_PUSH_TRACK 128\n \n /* Returns a transport suitable for the url */\n struct transport *transport_get(struct remote *, const char *);\n"},{"id":"131484","messageId":"20100113154310.GA7348@Knoppix","threadId":"22201","inReplyTo":"op.u6g8jnixg402ra@nb-04","subject":"Re: [PATCH] git push --track","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2010-01-13T15:43:10Z","receivedAt":"2010-01-13T15:43:10Z","isPatch":true,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Wed, Jan 13, 2010 at 04:12:49PM +0100, Rudolf Polzer wrote:\n> Hi,\n> \n> I'd like a feature to automatically \"transform\" a non-tracking local\n> branch into a tracking branch on push. A patch to do that is\n> attached.\n\nThe patches should be sent inline, together with commit messages\n(unless you are asked to resend as attachment because of whitespace\nmangling). Attached patches are very hard to comment on.\n\n> Are there any chances for this getting added to official git - or an\n> alternate convenient way convert a local to a tracking branch?\n\nThis is missing sign-off. It can't be included without it.\n\nAlso couple comments:\n\n- Some lines look way too long (~160 chars, should be max 80 unles\nit would linebreak error message).\n- Should the tracking be set up even if only part of ref update suceeded\n(for those that succeeded), not requiring all to succeed?\n- Is --track the best name for this?\n\n-Ilari\n"},{"id":"131485","messageId":"op.u6haiiiog402ra@nb-04","threadId":"22201","inReplyTo":"20100113154310.GA7348@Knoppix","subject":"Re: [PATCH] git push --track","fromName":"Rudolf Polzer","fromEmail":"divverent@alientrap.org","sentAt":"2010-01-13T15:55:20Z","receivedAt":"2010-01-13T15:55:20Z","isPatch":true,"sender":{"key":"divverent@alientrap.org","avatar":null},"body":"On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara \n wrote:\n\n> On Wed, Jan 13, 2010 at 04:12:49PM +0100, Rudolf Polzer wrote:\n>> Hi,\n>>\n>> I'd like a feature to automatically \"transform\" a non-tracking local\n>> branch into a tracking branch on push. A patch to do that is\n>> attached.\n>\n> The patches should be sent inline, together with commit messages\n> (unless you are asked to resend as attachment because of whitespace\n> mangling). Attached patches are very hard to comment on.\n>\n>> Are there any chances for this getting added to official git - or an\n>> alternate convenient way convert a local to a tracking branch?\n>\n> This is missing sign-off. It can't be included without it.\n\nOf course, but I assume the sign-off would not be by me, but by some of \nthe git developers, and would depend on whether they actually want this \nfeature.\n\n> Also couple comments:\n>\n> - Some lines look way too long (~160 chars, should be max 80 unles\n> it would linebreak error message).\n\nYes, also I got told that I used the wrong braces style... well, fixed \nthat.\n\n> - Should the tracking be set up even if only part of ref update suceeded\n> (for those that succeeded), not requiring all to succeed?\n\nGood point, but I simply see no clean way to set it up for the succeeded \nrefs. Would be a nice idea for improvement of this.\n\n> - Is --track the best name for this?\n\nI am assuming this, because this is what git-checkout and git-branch use \nfor the same thing.\n\nAs I am absolutely not sure if with Opera I can include the file as is, I \nalso provided it on http://nopaste.linux-dev.org/?6248 this time.\n\nBest regards,\n\nRudolf\n\n\n From 123598516c7d4e1f83591e8dae64e2c76dc87c90 Mon Sep 17 00:00:00 2001\nFrom: Rudolf Polzer \nDate: Wed, 13 Jan 2010 16:42:04 +0100\nSubject: [PATCH 1/2] Add a feature \"git push --track\" to automatically \nmake the pushed branches tracking\n\n---\n builtin-push.c | 33 +++++++++++++++++++++++++++++++++\n transport.h | 1 +\n 2 files changed, 34 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-push.c b/builtin-push.c\nindex 28a26e7..e5b66a3 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -7,6 +7,7 @@\n #include \"builtin.h\"\n #include \"remote.h\"\n #include \"transport.h\"\n+#include \"branch.h\"\n #include \"parse-options.h\"\n\n static const char * const push_usage[] = {\n@@ -115,6 +116,36 @@ static int push_with_options(struct transport \n*transport, int flags)\n \t\tfprintf(stderr, \"Pushing to %s\\n\", transport->url);\n \terr = transport_push(transport, refspec_nr, refspec, flags,\n \t\t\t &nonfastforward);\n+\tif (err == 0 && flags & TRANSPORT_PUSH_TRACK) {\n+\t\tstruct ref *remote_refs =\n+\t\t\ttransport->get_refs_list(transport, 1);\n+\t\tstruct ref *local_refs = get_local_heads();\n+\t\tint match_flags = 0;\n+\t\tif (flags & TRANSPORT_PUSH_ALL)\n+\t\t\tmatch_flags |= MATCH_REFS_ALL;\n+\t\tif (flags & TRANSPORT_PUSH_MIRROR)\n+\t\t\tmatch_flags |= MATCH_REFS_MIRROR;\n+\t\tif(!(flags & TRANSPORT_PUSH_DRY_RUN))\n+\t\tif(!match_refs(local_refs, &remote_refs, refspec_nr, refspec,\n+\t\t\t\t\tmatch_flags)) {\n+\t\t\tstruct ref *next = remote_refs;\n+\t\t\twhile(next) {\n+\t\t\t\tif(next->peer_ref && *next->peer_ref->name &&\n+\t\t\t\t\t\t*next->name &&\n+\t\t\t\t\t\tnext->peer_ref->new_sha1 &&\n+\t\t\t\t\t\t!is_null_sha1(next->peer_ref->new_sha1))\n+\t\t\t\t{\n+\t\t\t\t\tif (!prefixcmp(next->peer_ref->name,\n+\t\t\t\t\t\t\t\t\"refs/heads/\"))\n+\t\t\t\t\t\tinstall_branch_config(BRANCH_CONFIG_VERBOSE,\n+\t\t\t\t\t\t\t\tnext->peer_ref->name + 11,\n+\t\t\t\t\t\t\t\ttransport->remote->name,\n+\t\t\t\t\t\t\t\tnext->name);\n+\t\t\t\t}\n+\t\t\t\tnext = next->next;\n+\t\t\t}\n+\t\t}\n+\t}\n \tif (err != 0)\n \t\terror(\"failed to push some refs to '%s'\", transport->url);\n\n@@ -218,6 +249,8 @@ int cmd_push(int argc, const char **argv, const char \n*prefix)\n \t\tOPT_BOOLEAN( 0 , \"thin\", &thin, \"use thin pack\"),\n \t\tOPT_STRING( 0 , \"receive-pack\", &receivepack, \"receive-pack\", \"receive \npack program\"),\n \t\tOPT_STRING( 0 , \"exec\", &receivepack, \"receive-pack\", \"receive pack \nprogram\"),\n+\t\tOPT_BIT('t', \"track\", &flags, \"set up tracking mode (see git-pull(1))\",\n+\t\t\tTRANSPORT_PUSH_TRACK),\n \t\tOPT_END()\n \t};\n\ndiff --git a/transport.h b/transport.h\nindex 9e74406..8a9c776 100644\n--- a/transport.h\n+++ b/transport.h\n@@ -74,6 +74,7 @@ struct transport {\n #define TRANSPORT_PUSH_VERBOSE 16\n #define TRANSPORT_PUSH_PORCELAIN 32\n #define TRANSPORT_PUSH_QUIET 64\n+#define TRANSPORT_PUSH_TRACK 128\n\n /* Returns a transport suitable for the url */\n struct transport *transport_get(struct remote *, const char *);\n-- \n1.6.3.3\n\n\n From bbdd185ac43fb789f35d0177697486457af87fd0 Mon Sep 17 00:00:00 2001\nFrom: Rudolf Polzer \nDate: Wed, 13 Jan 2010 16:47:24 +0100\nSubject: [PATCH 2/2] tracking into Docs\n\n---\n Documentation/git-push.txt | 8 ++++++++\n 1 files changed, 8 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex e3eb1e8..ebaa67b 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -82,6 +82,14 @@ nor in any Push line of the corresponding remotes \nfile---see below).\n \tif the configuration option `remote..mirror` is\n \tset.\n\n+-t::\n+--track::\n+\tWhen pushing, set up \"upstream\" configuration. See\n+\t\"--track\" in linkgit:git-branch[1] for details. All\n+\trefspecs that have a branch as source ref will be turned\n+\tinto tracking branches if they are not already, and in any case\n+\tadjusted to track the given remote and ref on the remote side.\n+\n -n::\n --dry-run::\n \tDo everything except actually send the updates.\n-- \n1.6.3.3\n"},{"id":"131489","messageId":"20100113162736.GA7505@Knoppix","threadId":"22201","inReplyTo":"op.u6haiiiog402ra@nb-04","subject":"Re: [PATCH] git push --track","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2010-01-13T16:27:36Z","receivedAt":"2010-01-13T16:27:36Z","isPatch":true,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Wed, Jan 13, 2010 at 04:55:20PM +0100, Rudolf Polzer wrote:\n> On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara\n> wrote:\n> \n> >On Wed, Jan 13, 2010 at 04:12:49PM +0100, Rudolf Polzer wrote:\n> >>Hi,\n> >>\n> \n> Of course, but I assume the sign-off would not be by me, but by some\n> of the git developers, and would depend on whether they actually\n> want this feature.\n\nIt would need sign-off by you. Even if you took the code from somewhere\n(and then it would need theirs as well) and passed it along.\n \n> >- Should the tracking be set up even if only part of ref update suceeded\n> >(for those that succeeded), not requiring all to succeed?\n> \n> Good point, but I simply see no clean way to set it up for the\n> succeeded refs. Would be a nice idea for improvement of this.\n\nAh, that is only known in transport_push and what it calls (and transport_push\nis last point to insert common functionality)...\n \n> @@ -218,6 +249,8 @@ int cmd_push(int argc, const char **argv, const\n> char *prefix)\n> \t\tOPT_BOOLEAN( 0 , \"thin\", &thin, \"use thin pack\"),\n> \t\tOPT_STRING( 0 , \"receive-pack\", &receivepack, \"receive-pack\",\n> \"receive pack program\"),\n> \t\tOPT_STRING( 0 , \"exec\", &receivepack, \"receive-pack\", \"receive\n> pack program\"),\n> +\t\tOPT_BIT('t', \"track\", &flags, \"set up tracking mode (see git-pull(1))\",\n> +\t\t\tTRANSPORT_PUSH_TRACK),\n> \t\tOPT_END()\n> \t};\n\nLinewrap damage.\n\n-Ilari\n"},{"id":"131490","messageId":"vpqr5puarlq.fsf@bauges.imag.fr","threadId":"22201","inReplyTo":"op.u6haiiiog402ra@nb-04","subject":"Re: [PATCH] git push --track","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-01-13T16:37:21Z","receivedAt":"2010-01-13T16:37:21Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Rudolf Polzer\" writes:\n\n> Of course, but I assume the sign-off would not be by me, but by some\n> of the git developers, and would depend on whether they actually want\n> this feature.\n\nRead Documentation/SubmittingPatches in Git's source to make sure you\nunderstand what Signed-off-by: means for the Git project.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"131553","messageId":"871vht7cs2.fsf@catnip.gol.com","threadId":"22201","inReplyTo":"op.u6g8jnixg402ra@nb-04","subject":"Re: [PATCH] git push --track","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-01-14T00:25:49Z","receivedAt":"2010-01-14T00:25:49Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"\"Rudolf Polzer\" writes:\n> I'd like a feature to automatically \"transform\" a non-tracking local\n> branch into a tracking branch on push. A patch to do that is attached.\n\nYay!!\n\nI've wanted this for a long time, but discussions about it always seem\nto end up petering out...\n\n> git branch mybranch\n> git checkout mybranch\n> ...\n> git push --track origin mybranch:mybranch\n\nDoes it default to the current branch so you can just say \"git push --track origin\"?\n\nI hope this can be added to the distro...\n\nThanks,\n\n-Miles\n\n-- \nOpposition, n. In politics the party that prevents the Goverment from running\namok by hamstringing it.\n"},{"id":"131555","messageId":"87vdf55y3m.fsf@catnip.gol.com","threadId":"22201","inReplyTo":"20100113154310.GA7348@Knoppix","subject":"Re: [PATCH] git push --track","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-01-14T00:28:13Z","receivedAt":"2010-01-14T00:28:13Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Ilari Liusvaara writes:\n> - Is --track the best name for this?\n\nI think \"--track\" is absolutely the right name for this option -- it's\nthe option name used for \"set up tracking\" option in other commands, and\nit's just very natural (when I've thought about implementing a similar\nfunctionality myself, I also chose the name \"--track\").\n\n-Miles\n\n-- \nYouth, n. The Period of Possibility, when Archimedes finds a fulcrum,\nCassandra has a following and seven cities compete for the honor of endowing a\nliving Homer.\n"},{"id":"131554","messageId":"alpine.DEB.1.00.1001140132110.4985@pacific.mpi-cbg.de","threadId":"22201","inReplyTo":"871vht7cs2.fsf@catnip.gol.com","subject":"Re: [PATCH] git push --track","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-01-14T00:33:43Z","receivedAt":"2010-01-14T00:33:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Jan 2010, Miles Bader wrote:\n\n> \"Rudolf Polzer\" writes:\n> > I'd like a feature to automatically \"transform\" a non-tracking local \n> > branch into a tracking branch on push. A patch to do that is attached.\n> \n> Yay!!\n> \n> I've wanted this for a long time, but discussions about it always seem \n> to end up petering out...\n\nThat is not fair. I came up with a patch already years ago. You could \nalways have applied it to your own source, maybe after tweaking. And then \nmaybe lobbying for it.\n\nCiao,\nDscho\n"},{"id":"131556","messageId":"fc339e4a1001131636m6e797112id1ecc7fd909311a0@mail.gmail.com","threadId":"22201","inReplyTo":"alpine.DEB.1.00.1001140132110.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH] git push --track","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-01-14T00:36:06Z","receivedAt":"2010-01-14T00:36:06Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"On Thu, Jan 14, 2010 at 9:33 AM, Johannes Schindelin\n wrote:\n>> I've wanted this for a long time, but discussions about it always seem\n>> to end up petering out...\n>\n> That is not fair.  I came up with a patch already years ago.  You could\n> always have applied it to your own source, maybe after tweaking.  And then\n> maybe lobbying for it.\n\nAh, sorry, I didn't mean anything against your patch, I just didn't\nknow about it.\nI don't track this list as well as I could....\n\n[Do you have a pointer to your patch?]\n\nThanks,\n\n-Miles\n\n-- \nDo not taunt Happy Fun Ball.\n"},{"id":"131557","messageId":"87k4vl5x9s.fsf@catnip.gol.com","threadId":"22201","inReplyTo":"871vht7cs2.fsf@catnip.gol.com","subject":"Re: [PATCH] git push --track","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-01-14T00:46:07Z","receivedAt":"2010-01-14T00:46:07Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"BTW, I was _just_ going to post a message saying \"whatever happened to\npush --track\", but then decided to check the list once more, and saw\nyour message...!\n\n-Miles\n\n-- \nDawn, n. When men of reason go to bed.\n"},{"id":"131570","messageId":"be6fef0d1001131727r128c7727td2b948018d308719@mail.gmail.com","threadId":"22201","inReplyTo":"op.u6g8jnixg402ra@nb-04","subject":"Re: [PATCH] git push --track","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-01-14T01:27:26Z","receivedAt":"2010-01-14T01:27:26Z","isPatch":true,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Wed, Jan 13, 2010 at 11:12 PM, Rudolf Polzer wrote:\n> Hi,\n>\n> I'd like a feature to automatically \"transform\" a non-tracking local branch\n> into a tracking branch on push. A patch to do that is attached.\n>\n> Usage:\n>\n> git branch mybranch\n> git checkout mybranch\n> ...\n> git push --track origin mybranch:mybranch\n>\n> will not just perform the push, but also write a block\n>\n> [branch \"mybranch\"]\n>        remote = origin\n>        merge = refs/heads/mybranch\n>\n> to the git configuration so the branch becomes tracking.\n>\n> This should be a simpler alternative to the otherwise usual procedure\n>\n> git push origin mybranch:mybranch\n> git config branch.mybranch.remote origin\n> git config branch.mybranch.merge refs/heads/mybranch\n>\n> Are there any chances for this getting added to official git - or an\n> alternate convenient way convert a local to a tracking branch?\n\nbefore I put up my comments on the patch, I wonder if git-push is the\nbest place to add this feature, as git-push usually deals with\n\"pushing\" data to another repo.\n\nI think git-branch would be a better place to do this.\n\n-- \nCheers,\nRay Chuan\n"},{"id":"131571","messageId":"87eilt5uzx.fsf@catnip.gol.com","threadId":"22201","inReplyTo":"be6fef0d1001131727r128c7727td2b948018d308719@mail.gmail.com","subject":"Re: [PATCH] git push --track","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-01-14T01:35:14Z","receivedAt":"2010-01-14T01:35:14Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Tay Ray Chuan writes:\n> before I put up my comments on the patch, I wonder if git-push is the\n> best place to add this feature, as git-push usually deals with\n> \"pushing\" data to another repo.\n>\n> I think git-branch would be a better place to do this.\n\nNo. I think push is absolutely the right place to do it.\n\nI very often create local branches and only later decide that I'd also\nlike to push them to a remote -- but just as often, or more often, I\nnever do so. It would be extremely annoying if I had to make that\ndecision at branch-time.\n\n-Miles\n\n-- \nPray, v. To ask that the laws of the universe be annulled in behalf of a\nsingle petitioner confessedly unworthy.\n"},{"id":"131572","messageId":"be6fef0d1001131737i59b2e843ib032c30027520b54@mail.gmail.com","threadId":"22201","inReplyTo":"87eilt5uzx.fsf@catnip.gol.com","subject":"Re: [PATCH] git push --track","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-01-14T01:37:55Z","receivedAt":"2010-01-14T01:37:55Z","isPatch":true,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Thu, Jan 14, 2010 at 9:35 AM, Miles Bader wrote:\n> Tay Ray Chuan writes:\n>> before I put up my comments on the patch, I wonder if git-push is the\n>> best place to add this feature, as git-push usually deals with\n>> \"pushing\" data to another repo.\n>>\n>> I think git-branch would be a better place to do this.\n>\n> No.  I think push is absolutely the right place to do it.\n>\n> I very often create local branches and only later decide that I'd also\n> like to push them to a remote -- but just as often, or more often, I\n> never do so.  It would be extremely annoying if I had to make that\n> decision at branch-time.\n\nI'm not saying that the feature should belong to git-branch and so you\nhave to make this decision at branch time - I'm saying that since this\nhas got to do with modifying branches (sort of), it should be in\nthere.\n\n-- \nCheers,\nRay Chuan\n"},{"id":"131573","messageId":"fc339e4a1001131749s4da9526bs13406571773c38fd@mail.gmail.com","threadId":"22201","inReplyTo":"be6fef0d1001131737i59b2e843ib032c30027520b54@mail.gmail.com","subject":"Re: [PATCH] git push --track","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-01-14T01:49:00Z","receivedAt":"2010-01-14T01:49:00Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"On Thu, Jan 14, 2010 at 10:37 AM, Tay Ray Chuan wrote:\n>> I very often create local branches and only later decide that I'd also\n>> like to push them to a remote -- but just as often, or more often, I\n>> never do so.  It would be extremely annoying if I had to make that\n>> decision at branch-time.\n>\n> I'm not saying that the feature should belong to git-branch and so you\n> have to make this decision at branch time - I'm saying that since this\n> has got to do with modifying branches (sort of), it should be in\n> there.\n\nI, and it appears other people, want to make this association at\npush-time -- that's almost always when I make the decision \"I'd like\nto track this\" -- so the most convenient and intuitive thing would be\nto have a --track option to push.\n\nOf course there could _also_ be some sort of branch sub-command (or\nanother command) to setup or change tracking state without pushing.\nBut \"push --track\" is more important for normal usage I think.\n\n-miles\n\n-- \nDo not taunt Happy Fun Ball.\n"},{"id":"131574","messageId":"be6fef0d1001131758x51329f01qeccf477cae54561e@mail.gmail.com","threadId":"22201","inReplyTo":"fc339e4a1001131749s4da9526bs13406571773c38fd@mail.gmail.com","subject":"Re: [PATCH] git push --track","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-01-14T01:58:17Z","receivedAt":"2010-01-14T01:58:17Z","isPatch":true,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"On Thu, Jan 14, 2010 at 9:49 AM, Miles Bader wrote:\n> I, and it appears other people, want to make this association at\n> push-time -- that's almost always when I make the decision \"I'd like\n> to track this\" -- so the most convenient and intuitive thing would be\n> to have a --track option to push.\n>\n> Of course there could _also_ be some sort of branch sub-command (or\n> another command) to setup or change tracking state without pushing.\n> But \"push --track\" is more important for normal usage I think.\n\nOk, I see your point.\n\n-- \nCheers,\nRay Chuan\n"},{"id":"131579","messageId":"be6fef0d1001132121w4e25c7f0j760d71c136012401@mail.gmail.com","threadId":"22201","inReplyTo":"op.u6haiiiog402ra@nb-04","subject":"Re: [PATCH] git push --track","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-01-14T05:21:17Z","receivedAt":"2010-01-14T05:21:17Z","isPatch":true,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\ngenerally, it would be better if you could add some tests for this.\n\nIf I'm not wrong, the place to put it would be t5516-fetch-push.sh.\n\nOn Wed, Jan 13, 2010 at 11:55 PM, Rudolf Polzer wrote:\n> On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara\n> wrote:\n\nplease don't drop people from the Cc list - especially when you're\nreplying to somebody!\n\n> From 123598516c7d4e1f83591e8dae64e2c76dc87c90 Mon Sep 17 00:00:00 2001\n> From: Rudolf Polzer \n> Date: Wed, 13 Jan 2010 16:42:04 +0100\n> Subject: [PATCH 1/2] Add a feature \"git push --track\" to automatically make\n> the pushed branches tracking\n\nEach patch should be sent out in its own mail. (As Matthieu has\nrecommended, you should check out Documentation/SubmittingPatches.)\n\n>  static const char * const push_usage[] = {\n> @@ -115,6 +116,36 @@ static int push_with_options(struct transport\n> *transport, int flags)\n>                fprintf(stderr, \"Pushing to %s\\n\", transport->url);\n>        err = transport_push(transport, refspec_nr, refspec, flags,\n>                             &nonfastforward);\n> +       if (err == 0 && flags & TRANSPORT_PUSH_TRACK) {\n> +               struct ref *remote_refs =\n> +                       transport->get_refs_list(transport, 1);\n> +               struct ref *local_refs = get_local_heads();\n> +               int match_flags = 0;\n> +               if (flags & TRANSPORT_PUSH_ALL)\n> +                       match_flags |= MATCH_REFS_ALL;\n> +               if (flags & TRANSPORT_PUSH_MIRROR)\n> +                       match_flags |= MATCH_REFS_MIRROR;\n> +               if(!(flags & TRANSPORT_PUSH_DRY_RUN))\n> +               if(!match_refs(local_refs, &remote_refs, refspec_nr,\n> refspec,\n> +                                       match_flags)) {\n\nIt would be better if you can move this to\ntransport.c::transport_push(). It repeats what's already there, so you\ndon't have to configure match_flags, nor call match_refs, etc.\n\n> +                       struct ref *next = remote_refs;\n> +                       while(next) {\n> [snip]\n> +                               next = next->next;\n\nIn most places, this is done like this:\n\n struct ref* ref;\n for (ref = remote_refs; ref; ref = ref->next) {\n ...\n }\n\n-- \nCheers,\nRay Chuan\n"},{"id":"131605","messageId":"20100114154154.6117@nanako3.lavabit.com","threadId":"22201","inReplyTo":"op.u6g8jnixg402ra@nb-04","subject":"Re: [PATCH] git push --track","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2010-01-14T06:41:54Z","receivedAt":"2010-01-14T06:41:54Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Rudolf Polzer \n\n> I'd like a feature to automatically \"transform\" a non-tracking local\n> branch into a tracking branch on push. A patch to do that is attached.\n\nHow well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in\n http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"131611","messageId":"20100114070000.GA1528@rm.endoftheinternet.org","threadId":"22201","inReplyTo":"be6fef0d1001132121w4e25c7f0j760d71c136012401@mail.gmail.com","subject":"Re: [PATCH] git push --track","fromName":"Rudolf Polzer","fromEmail":"divverent@alientrap.org","sentAt":"2010-01-14T07:00:02Z","receivedAt":"2010-01-14T07:00:02Z","isPatch":true,"sender":{"key":"divverent@alientrap.org","avatar":null},"body":"On Thu, Jan 14, 2010 at 01:21:17PM +0800, Tay Ray Chuan wrote:\n> Hi,\n> \n> generally, it would be better if you could add some tests for this.\n> \n> If I'm not wrong, the place to put it would be t5516-fetch-push.sh.\n\nCan add that, but it seems like it won't go in anyway from the discussion here,\nso it's probably not worth working on it. Sad.\n\n> On Wed, Jan 13, 2010 at 11:55 PM, Rudolf Polzer wrote:\n> > On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara\n> > wrote:\n> \n> please don't drop people from the Cc list - especially when you're\n> replying to somebody!\n\nI did not drop anyone, but simply replied from my newsreader. I really don't\nwant to subscribe to a mailing list and then get hundreds of emails a day.\n\n> > From 123598516c7d4e1f83591e8dae64e2c76dc87c90 Mon Sep 17 00:00:00 2001\n> > From: Rudolf Polzer \n> > Date: Wed, 13 Jan 2010 16:42:04 +0100\n> > Subject: [PATCH 1/2] Add a feature \"git push --track\" to automatically make\n> > the pushed branches tracking\n> \n> Each patch should be sent out in its own mail. (As Matthieu has\n> recommended, you should check out Documentation/SubmittingPatches.)\n\nSo, using a newsreader is not accepted practice? Why is the mailing list on a\nnewsgroup then?\n\n> >  static const char * const push_usage[] = {\n> > @@ -115,6 +116,36 @@ static int push_with_options(struct transport\n> > *transport, int flags)\n> >                fprintf(stderr, \"Pushing to %s\\n\", transport->url);\n> >        err = transport_push(transport, refspec_nr, refspec, flags,\n> >                             &nonfastforward);\n> > +       if (err == 0 && flags & TRANSPORT_PUSH_TRACK) {\n> > +               struct ref *remote_refs =\n> > +                       transport->get_refs_list(transport, 1);\n> > +               struct ref *local_refs = get_local_heads();\n> > +               int match_flags = 0;\n> > +               if (flags & TRANSPORT_PUSH_ALL)\n> > +                       match_flags |= MATCH_REFS_ALL;\n> > +               if (flags & TRANSPORT_PUSH_MIRROR)\n> > +                       match_flags |= MATCH_REFS_MIRROR;\n> > +               if(!(flags & TRANSPORT_PUSH_DRY_RUN))\n> > +               if(!match_refs(local_refs, &remote_refs, refspec_nr,\n> > refspec,\n> > +                                       match_flags)) {\n> \n> It would be better if you can move this to\n> transport.c::transport_push(). It repeats what's already there, so you\n> don't have to configure match_flags, nor call match_refs, etc.\n\nThen I have to duplicate it in the rsync specific push code too. Otherwise,\nagreed.\n\n> > +                       struct ref *next = remote_refs;\n> > +                       while(next) {\n> > [snip]\n> > +                               next = next->next;\n> \n> In most places, this is done like this:\n> \n> struct ref* ref;\n> for (ref = remote_refs; ref; ref = ref->next) {\n> ...\n> }\n\nSure, could do that too, I got this loop from the loop that frees a ref list.\n\nBest regards,\n\nRudolf\n"},{"id":"131609","messageId":"20100114070108.GB1528@rm.endoftheinternet.org","threadId":"22201","inReplyTo":"871vht7cs2.fsf@catnip.gol.com","subject":"Re: [PATCH] git push --track","fromName":"Rudolf Polzer","fromEmail":"divverent@alientrap.org","sentAt":"2010-01-14T07:01:08Z","receivedAt":"2010-01-14T07:01:08Z","isPatch":true,"sender":{"key":"divverent@alientrap.org","avatar":null},"body":"On Thu, Jan 14, 2010 at 09:25:49AM +0900, Miles Bader wrote:\n> \"Rudolf Polzer\" writes:\n> > I'd like a feature to automatically \"transform\" a non-tracking local\n> > branch into a tracking branch on push. A patch to do that is attached.\n> \n> Yay!!\n> \n> I've wanted this for a long time, but discussions about it always seem\n> to end up petering out...\n> \n> > git branch mybranch\n> > git checkout mybranch\n> > ...\n> > git push --track origin mybranch:mybranch\n> \n> Does it default to the current branch so you can just say \"git push --track origin\"?\n\nIt does the very same decisions as push. Basically, it is \"whatever got pushed,\nmark as tracking\".\n\nBest regards,\n\nRudolf\n"},{"id":"131610","messageId":"20100114070316.GC1528@rm.endoftheinternet.org","threadId":"22201","inReplyTo":"be6fef0d1001131727r128c7727td2b948018d308719@mail.gmail.com","subject":"Re: [PATCH] git push --track","fromName":"Rudolf Polzer","fromEmail":"divverent@alientrap.org","sentAt":"2010-01-14T07:03:16Z","receivedAt":"2010-01-14T07:03:16Z","isPatch":true,"sender":{"key":"divverent@alientrap.org","avatar":null},"body":"On Thu, Jan 14, 2010 at 09:27:26AM +0800, Tay Ray Chuan wrote:\n> before I put up my comments on the patch, I wonder if git-push is the\n> best place to add this feature, as git-push usually deals with\n> \"pushing\" data to another repo.\n> \n> I think git-branch would be a better place to do this.\n\nI think git-branch can already do this: after pushing, you can do git branch -f\n--track origin/mybranch.\n\nBut the goal of this is to postponing the decision to track to the push time,\nand adding as little as possible extra commands/options to do this.\n"},{"id":"131607","messageId":"20100114070812.GD1528@rm.endoftheinternet.org","threadId":"22201","inReplyTo":"20100114154154.6117@nanako3.lavabit.com","subject":"Re: [PATCH] git push --track","fromName":"Rudolf Polzer","fromEmail":"divverent@alientrap.org","sentAt":"2010-01-14T07:08:13Z","receivedAt":"2010-01-14T07:08:13Z","isPatch":true,"sender":{"key":"divverent@alientrap.org","avatar":null},"body":"On Thu, Jan 14, 2010 at 03:41:54PM +0900, Nanako Shiraishi wrote:\n> Quoting Rudolf Polzer \n> \n> > I'd like a feature to automatically \"transform\" a non-tracking local\n> > branch into a tracking branch on push. A patch to do that is attached.\n> \n> How well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in\n> http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390\n\nI don't really think this has much to do with the other. git branch\n--will-track still means one needs to know it at branch setup time, and git\npull --remember still means one needs to type way more stuff than with a simple\npush --track.\n\nBut well, given the discussion here I see the feature is essentially rejected,\nand already was rejected a previous time. Will probably forget about this and\nmake a shell script that does for ME what I want.\n\nBest regards,\n\nRudolf\n"},{"id":"131608","messageId":"20100114071634.GA20567@coredump.intra.peff.net","threadId":"22201","inReplyTo":"op.u6haiiiog402ra@nb-04","subject":"Re: [PATCH] git push --track","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-01-14T07:16:35Z","receivedAt":"2010-01-14T07:16:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 13, 2010 at 04:55:20PM +0100, Rudolf Polzer wrote:\n\n> >- Should the tracking be set up even if only part of ref update suceeded\n> >(for those that succeeded), not requiring all to succeed?\n> \n> Good point, but I simply see no clean way to set it up for the\n> succeeded refs. Would be a nice idea for improvement of this.\n\nI don't think it's that hard. In fact, I did a preliminary patch for it\nabout a year ago:\n\n http://article.gmane.org/gmane.comp.version-control.git/107750\n\nThat patch was held up because there were a lot of cleanups needed in\ntransport.c before it would make sense (read the whole thread for\ndetails). I think most of those cleanups have happened in the meantime,\nso it would be pretty straightforward to use the same setup_tracking()\nfunction and just call it from the right spot in transport.c. But I\nhaven't actually looked at this topic since the above-referenced thread.\n\n-Peff\n"},{"id":"131631","messageId":"alpine.DEB.1.00.1001141130210.4985@pacific.mpi-cbg.de","threadId":"22201","inReplyTo":"20100114154154.6117@nanako3.lavabit.com","subject":"Re: [PATCH] git push --track","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-01-14T10:31:43Z","receivedAt":"2010-01-14T10:31:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Jan 2010, Nanako Shiraishi wrote:\n\n> Quoting Rudolf Polzer \n> \n> > I'd like a feature to automatically \"transform\" a non-tracking local\n> > branch into a tracking branch on push. A patch to do that is attached.\n> \n> How well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in\n> http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390\n\nThank you for looking up that reference.\n\nDo you remember what the outcome was? (Peff mentioned that there was some \ntalk about putting this code into transport.c and some needed \nrestructurings, but I do not remember the details, and I did not have time \nto follow the development of that file in the recent months.)\n\nCiao,\nDscho\n"},{"id":"131643","messageId":"46a038f91001140544u64dd7eefn94625cdc40881cd6@mail.gmail.com","threadId":"22201","inReplyTo":"871vht7cs2.fsf@catnip.gol.com","subject":"Re: [PATCH] git push --track","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2010-01-14T13:44:10Z","receivedAt":"2010-01-14T13:44:10Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Thu, Jan 14, 2010 at 1:25 AM, Miles Bader wrote:\n> Yay!!\n\nYay too!\n\n>> git push --track origin mybranch:mybranch\n>\n> Does it default to the current branch so you can just say \"git push --track origin\"?\n\nCan we take this further and say\n\n git push --make-a-new-repo-and-track-it --shared\ngit+ssh://foo.bar/var/git/mynewthing.git master:master\n\n...?\n\n\n\nOf course it'd only work if you have full ssh access, unless the git\nserver learns a new command to mkdir (in sane and approved locations).\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"131644","messageId":"alpine.DEB.1.00.1001141509230.3029@intel-tinevez-2-302","threadId":"22201","inReplyTo":"46a038f91001140544u64dd7eefn94625cdc40881cd6@mail.gmail.com","subject":"Re: [PATCH] git push --track","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-01-14T14:16:55Z","receivedAt":"2010-01-14T14:16:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Jan 2010, Martin Langhoff wrote:\n\n> Can we take this further and say\n> \n> git push --make-a-new-repo-and-track-it --shared\n> git+ssh://foo.bar/var/git/mynewthing.git master:master\n> \n> ...?\n> \n> \n\nYou mean just like http pushing?\n\n> Of course it'd only work if you have full ssh access, unless the git \n> server learns a new command to mkdir (in sane and approved locations).\n\nYou mean a new \"init\" command a la \"git --git-dir=bla.git init\", which \n_does_ mkdir the directory.\n\nCiao,\nDscho\n"},{"id":"131645","messageId":"vpqiqb4lq4q.fsf@bauges.imag.fr","threadId":"22201","inReplyTo":"alpine.DEB.1.00.1001141509230.3029@intel-tinevez-2-302","subject":"Re: [PATCH] git push --track","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-01-14T14:25:57Z","receivedAt":"2010-01-14T14:25:57Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n\n>> Of course it'd only work if you have full ssh access, unless the git \n>> server learns a new command to mkdir (in sane and approved locations).\n>\n> You mean a new \"init\" command a la \"git --git-dir=bla.git init\", which \n> _does_ mkdir the directory.\n\nI think he meant\n\n git --git-dir=git+ssh://foo.bar/var/git/mynewthing.git init\n\nwhich doesn't.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"131647","messageId":"46a038f91001140635t38328ddbq3fc0bbced013e25b@mail.gmail.com","threadId":"22201","inReplyTo":"vpqiqb4lq4q.fsf@bauges.imag.fr","subject":"Re: [PATCH] git push --track","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2010-01-14T14:35:11Z","receivedAt":"2010-01-14T14:35:11Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Thu, Jan 14, 2010 at 3:25 PM, Matthieu Moy\n wrote:\n> I think he meant\n>\n>  git --git-dir=git+ssh://foo.bar/var/git/mynewthing.git init\n\nexacto. And push --track, all in one cmd.\n\nZooper easy for users.\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"131653","messageId":"20100114152727.GA26059@inner.home.ulmdo.de","threadId":"22201","inReplyTo":"vpqiqb4lq4q.fsf@bauges.imag.fr","subject":"Re: [PATCH] git push --track","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2010-01-14T15:27:27Z","receivedAt":"2010-01-14T15:27:27Z","isPatch":true,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Thu, 14 Jan 2010 15:25:57 +0000, Matthieu Moy wrote:\n> Johannes Schindelin writes:\n> \n> >> Of course it'd only work if you have full ssh access, unless the git \n> >> server learns a new command to mkdir (in sane and approved locations).\n> >\n> > You mean a new \"init\" command a la \"git --git-dir=bla.git init\", which \n> > _does_ mkdir the directory.\n> \n> I think he meant\n> \n> git --git-dir=git+ssh://foo.bar/var/git/mynewthing.git init\n> \n> which doesn't.\n\nBut 'ssh foo.bar git --git-dir=/var/git/mynewthing.git init' likely would.\n\nProbably missing a --bare somewhere; and I think that repo creation\npotentially needs too many things (like custom hook or access rights\nsetup) to be done via git push. Especially since you really only need\nto create an empty repo, and only if you didn't clone from the push\ntarget in the first place.\n\nAndreas\n"},{"id":"131682","messageId":"20100115072741.6117@nanako3.lavabit.com","threadId":"22201","inReplyTo":"alpine.DEB.1.00.1001141130210.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH] git push --track","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2010-01-14T22:27:41Z","receivedAt":"2010-01-14T22:27:41Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Johannes Schindelin \n\n> On Thu, 14 Jan 2010, Nanako Shiraishi wrote:\n>\n>> Quoting Rudolf Polzer \n>> \n>> > I'd like a feature to automatically \"transform\" a non-tracking local\n>> > branch into a tracking branch on push. A patch to do that is attached.\n>> \n>> How well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in\n>> http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390\n>\n> Thank you for looking up that reference.\n>\n> Do you remember what the outcome was?\n\nI summarized it when I reminded Junio on this topic last time and it is in the same discussion thread: http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=136216\n\nHere is an extended version.\n\n'git branch --will-track origin/topic topic origin/master' was proposed as a way to fork a topic branch at origin's master. Later 'git pull' will merge topic from origin to topic.\n\nThis is bad in two ways. It will force users to decide when the branch is created. It will not allow users to configure branch.topic.rebase variable.\n\n'git push --track' was suggested as a way to let users delay that decision.\n\n'git branch --configure' to update the same information for an existing branch was suggested as an alternative UI. An added benefit is that this approach will allow the same option to be used when creating a branch.\n\n'git pull --remember' that remembers the options used from the command line was suggested as a solution in addition to 'git branch --reconfigure'. Users can postpone the decision even more than 'git push --track', and it naturally supports setting branch.topic.rebase with 'git pull --rebase --remember'. It also has two additional benefits. 'push --track' configures what happens when you 'pull' (counter-intuitive), but 'pull --remember' makes 'pull' to change the setting used by 'pull' (much more natural). Also it does not add the confusing word 'track' to the interface (for a more detailed discussion on 'track', see http://article.gmane.org/gmane.comp.version-control.git/136785).\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"131687","messageId":"7vvdf4700w.fsf@alter.siamese.dyndns.org","threadId":"22201","inReplyTo":"20100114070000.GA1528@rm.endoftheinternet.org","subject":"Re: [PATCH] git push --track","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-14T23:13:35Z","receivedAt":"2010-01-14T23:13:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rudolf Polzer writes:\n\n>> Each patch should be sent out in its own mail. (As Matthieu has\n>> recommended, you should check out Documentation/SubmittingPatches.)\n>\n> So, using a newsreader is not accepted practice? Why is the mailing list on a\n> newsgroup then?\n\nI do read this list in a newsreader. When I say \"reply\" or \"follow-up\",\nthe response is sent out to the list via e-mail. Your newsreader should\nbe configurable in a similar way, I think.\n"},{"id":"131691","messageId":"7vr5ps5jx1.fsf@alter.siamese.dyndns.org","threadId":"22201","inReplyTo":"20100114070316.GC1528@rm.endoftheinternet.org","subject":"Re: [PATCH] git push --track","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-14T23:46:50Z","receivedAt":"2010-01-14T23:46:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rudolf Polzer writes:\n\n> On Thu, Jan 14, 2010 at 09:27:26AM +0800, Tay Ray Chuan wrote:\n>> before I put up my comments on the patch, I wonder if git-push is the\n>> best place to add this feature, as git-push usually deals with\n>> \"pushing\" data to another repo.\n>> \n>> I think git-branch would be a better place to do this.\n>\n> I think git-branch can already do this: after pushing, you can do git\n> branch -f --track origin/mybranch.\n>\n> But the goal of this is to postponing the decision to track to the push time,\n> and adding as little as possible extra commands/options to do this.\n\nThinking about this again (when was the last time we discussed it?), I\nlike the \"git branch -f\" suggestion (modulo one small nit). \n\nYes, \"push --track\" lets you postpone the decision; branching, working on\nit, pushing it out _and_ _then_ using your \"branch -f\" trick will let you\npostpone the decision even further. And it doesn't add --track to the UI.\n\nThe small nit is that \"branch -f --track me origin/me\" will happily\noverwrite \"me\", even when your \"me\" is not up to date with \"origin/me\",\nlosing commits.\n\nPerhaps we could teach \"branch --track me origin/me\" (i.e. no \"-f\") not to\nbarf even when \"me\" exists, as long as \"me\" is a subset of \"origin/me\",\nand treat it as a request to re-configure the upstream information for the\nexisting branch \"me\" and at the same time fast-forward it to \"origin/me\"?\n"},{"id":"131692","messageId":"7vmy0g5jql.fsf@alter.siamese.dyndns.org","threadId":"22201","inReplyTo":"20100115072741.6117@nanako3.lavabit.com","subject":"Re: [PATCH] git push --track","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-14T23:50:42Z","receivedAt":"2010-01-14T23:50:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> I summarized it when I reminded Junio on this topic last time and it is in the same discussion thread: http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=136216\n\nPlease wrap your lines for readability.\n\n> 'git pull --remember' that remembers...\n\nAlthough I admit I was the one who suggested it, and I think that it is\nthe most natural way to do this from the end user's point of view, from\nthe implementation point of view, it is the most difficult one in its\ncurrent form. \"git pull\" does not interpret refspecs and delegates all\nthe hard work to \"git fetch\".\n"},{"id":"131696","messageId":"87y6k06wgz.fsf@catnip.gol.com","threadId":"22201","inReplyTo":"7vr5ps5jx1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git push --track","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-01-15T00:30:20Z","receivedAt":"2010-01-15T00:30:20Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano writes:\n> Yes, \"push --track\" lets you postpone the decision; branching, working on\n> it, pushing it out _and_ _then_ using your \"branch -f\" trick will let you\n> postpone the decision even further.\n\nNonetheless, \"push --track\" is by far the most natural UI for the most\ncommon case, I think.\n\n> And it doesn't add --track to the UI.\n\nThat's not a positive...\n\nNone of this is _necessary_, it's to make git more convenient.\n\nHalfway-measures seem like \"oh the user can just use this branch\ncommand\" seem like, well, halfway measures. Sure, it would be nice to\nhave a branch command _too_, just to make it easier for branch\nmaintenance, but it's not what's really wanted.\n\n-Miles\n\n-- \nFaith, n. Belief without evidence in what is told by one who speaks without\nknowledge, of things without parallel.\n"},{"id":"131701","messageId":"7vvdf33onp.fsf@alter.siamese.dyndns.org","threadId":"22201","inReplyTo":"op.u6haiiiog402ra@nb-04","subject":"Re: [PATCH] git push --track","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-15T05:47:22Z","receivedAt":"2010-01-15T05:47:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Rudolf Polzer\" writes:\n\n> On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara\n> wrote:\n>\n>> - Some lines look way too long (~160 chars, should be max 80 unles\n>> it would linebreak error message).\n>\n> Yes, also I got told that I used the wrong braces style... well, fixed\n> that.\n\nYou didn't, although you tried to \"hide\" one level, which is even worse.\n\nIf you see overlong lines in patch text, it often is that the added\ncodepath is too deeply nested, and it often becomes much easier to\nunderstand if you split it into a separate smaller helper function.\n\nFor example, if you have\n\n\tif (A) {\n \tif (B) {\n \tdo something #1\n if (C) {\n \tdo something #2\n while (D) {\n \tif (E) {\n \tdo something #3\n\t\t\t\t\t}\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t}\n\nit often is much easier to read if you did:\n\n\tif (A)\n\t\thelper(...)\n\nand wrote a helper that is\n\n\thelper()\n {\n \tif (!B)\n \treturn\n\t\tdo something #1\n if (!C)\n \treturn\n\t\tdo something #2\n\t\twhile (D) {\n \tif (!E)\n \tcontinue\n\t\t\tdo something #3\n\t\t}\n\t}\n\n>> - Should the tracking be set up even if only part of ref update suceeded\n>> (for those that succeeded), not requiring all to succeed?\n\nI think giving configuration to the ones that succeeded, while not doing\nso for the ones that failed, would be the best.\n\n>> - Is --track the best name for this?\n\nMost probably not. \"git branch --track\" was already a mistake, whose\ndamage can be seen in the first message in this thread. I originally read\n\"this converts a local branch to a tracking branch\", and went \"Huh??? ---\nIs this patch running 'mv refs/heads/frotz refs/remotes/origin/frotz'?\nWhat's fun about it???\"\n\n> @@ -115,6 +116,36 @@ static int push_with_options(struct transport\n> *transport, int flags)\n> \t\tfprintf(stderr, \"Pushing to %s\\n\", transport->url);\n> \terr = transport_push(transport, refspec_nr, refspec, flags,\n> \t\t\t &nonfastforward);\n> +\tif (err == 0 && flags & TRANSPORT_PUSH_TRACK) {\n\nStyle:\n\n - Have SP between syntactic keyword and open parenthesis.\n\n - Never place an opening brace, except the one that begins a function\n body, on its own line;\n\nAlso the overlong line is merely a symptom that you are putting too much\nstuff in this function. The whole addition should probably be a helper\nfunction.\n\n> @@ -115,6 +116,33 @@ static int push_with_options(struct transport *transport, int flags)\n> \t\tfprintf(stderr, \"Pushing to %s\\n\", transport->url);\n> \terr = transport_push(transport, refspec_nr, refspec, flags,\n> \t\t\t &nonfastforward);\n> +\tif (err == 0 && flags & TRANSPORT_PUSH_TRACK)\n> +\t{\n> +\t\tstruct ref *remote_refs =\n> +\t\t\ttransport->get_refs_list(transport, 1);\n\nYou have already pushed by calling transport_push() before you got \"err\"\nback. Do you need to make a second, separate call to ls-remote here and\nif so why?\n\nI have a feeling that it is more appropriate to have the additional code\nin transport_push(), which gets ls-remote information, runs match_refs()\nand finally calls transport->push_refs(). I think the extra branch\nconfiguration would fit better inside the if block immediately after all\nthat happens, i.e.\n\n\tif (!(flags & TRANSPORT_PUSH_DRY_RUN)) {\n\t\tstruct ref *ref;\n\t\tfor (ref = remote_refs; ref; ref = ref->next)\n\t\t\tupdate_tracking_ref(transport->remote, ref, verbose);\n+\t\tif (flags & TRANSPORT_PUSH_RECONFIGURE_FORK)\n+\t\t\tconfigure_forked_branch(...);\n\t}\n\nin transport.c\n\n> +\t\tif(!(flags & TRANSPORT_PUSH_DRY_RUN))\n> +\t\tif(!match_refs(local_refs, &remote_refs, refspec_nr, refspec, match_flags))\n\nYuck; hiding the fact that you have an over-nested logic is not a way to\nfix it.\n"},{"id":"131717","messageId":"vpq3a277b39.fsf@bauges.imag.fr","threadId":"22201","inReplyTo":"7vr5ps5jx1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git push --track","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-01-15T13:26:50Z","receivedAt":"2010-01-15T13:26:50Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> The small nit is that \"branch -f --track me origin/me\" will happily\n> overwrite \"me\", even when your \"me\" is not up to date with \"origin/me\",\n> losing commits.\n\nAnd another issue is:\n\n$ git branch -f --track my-branch origin/my-branch\nfatal: Cannot force update the current branch.\n$ git branch --track my-branch origin/my-branch\nfatal: A branch named 'my-branch' already exists.\n\nActually, I just can't find a natural set of commands doing:\n\n1. create a branch (git checkout -b)\n2. work on it\n3. send it upstream (git push)\n4. set the upstream as tracking (???)\n\nwith the current version of Git. I just do 4. with $EDITOR\n.git/config ...\n\n> Perhaps we could teach \"branch --track me origin/me\" (i.e. no \"-f\") not to\n> barf even when \"me\" exists, as long as \"me\" is a subset of \"origin/me\",\n> and treat it as a request to re-configure the upstream information for the\n> existing branch \"me\" and at the same time fast-forward it to\n> \"origin/me\"?\n\n+1, and in addition, allow doing this on the checkout branch if it\ndoesn't actually change the reference (i.e. touch .git/config, not\n.git/refs/...).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"131721","messageId":"20100115134425.GA30986@rm.endoftheinternet.org","threadId":"22201","inReplyTo":"20100115072741.6117@nanako3.lavabit.com","subject":"Re: [PATCH] git push --track","fromName":"Rudolf Polzer","fromEmail":"divverent@alientrap.org","sentAt":"2010-01-15T13:44:26Z","receivedAt":"2010-01-15T13:44:26Z","isPatch":true,"sender":{"key":"divverent@alientrap.org","avatar":null},"body":"On Fri, Jan 15, 2010 at 07:27:41AM +0900, Nanako Shiraishi wrote:\n> 'git push --track' was suggested as a way to let users delay that decision.\n> \n> 'git branch --configure' to update the same information for an existing\n> branch was suggested as an alternative UI. An added benefit is that this\n> approach will allow the same option to be used when creating a branch.\n> \n> 'git pull --remember' that remembers the options used from the command line\n> was suggested as a solution in addition to 'git branch --reconfigure'. Users\n> can postpone the decision even more than 'git push --track', and it naturally\n> supports setting branch.topic.rebase with 'git pull --rebase --remember'. It\n> also has two additional benefits. 'push --track' configures what happens when\n> you 'pull' (counter-intuitive), but 'pull --remember' makes 'pull' to change\n> the setting used by 'pull' (much more natural). Also it does not add the\n> confusing word 'track' to the interface (for a more detailed discussion on\n> 'track', see http://article.gmane.org/gmane.comp.version-control.git/136785).\n\nStill requires you to specify the remote and the branch name twice.\n\nSo the workflow would be:\n\ngit push origin localbranch:remotebranch\n...\ngit pull --remember origin remotebranch:localbranch\n\ninstead of\n\ngit push --track origin localbranch:remotebranch\n...\ngit pull\n\nThe one thing I want to avoid, is specifying the \"origin\nlocalbranch:remotebranch\" stuff twice.\n\nDoesn't make git pull --remember a bad idea, it's good in many other cases. But\nin my specific use case, git push --track is the most useful one.\n\nRudolf\n"},{"id":"131722","messageId":"20100115140048.GB30986@rm.endoftheinternet.org","threadId":"22201","inReplyTo":"7vvdf33onp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git push --track","fromName":"Rudolf Polzer","fromEmail":"divverent@alientrap.org","sentAt":"2010-01-15T14:00:48Z","receivedAt":"2010-01-15T14:00:48Z","isPatch":true,"sender":{"key":"divverent@alientrap.org","avatar":null},"body":"On Thu, Jan 14, 2010 at 09:47:22PM -0800, Junio C Hamano wrote:\n> I have a feeling that it is more appropriate to have the additional code\n> in transport_push(), which gets ls-remote information, runs match_refs()\n> and finally calls transport->push_refs(). I think the extra branch\n> configuration would fit better inside the if block immediately after all\n> that happens, i.e.\n> \n> \tif (!(flags & TRANSPORT_PUSH_DRY_RUN)) {\n> \t\tstruct ref *ref;\n> \t\tfor (ref = remote_refs; ref; ref = ref->next)\n> \t\t\tupdate_tracking_ref(transport->remote, ref, verbose);\n> +\t\tif (flags & TRANSPORT_PUSH_RECONFIGURE_FORK)\n> +\t\t\tconfigure_forked_branch(...);\n> \t}\n> \n> in transport.c\n\nI thought about this place when making my patch, but didn't put it there\nbecause this function is not called in the rsync protocol (which defines\ntransport->push). So I instead did the logical step and went into the caller of\nthat function. Functionality-wise, it also isn't really a \"transport\" function\nbut part of pushing.\n\n> > +\t\tif(!(flags & TRANSPORT_PUSH_DRY_RUN))\n> > +\t\tif(!match_refs(local_refs, &remote_refs, refspec_nr, refspec, match_flags))\n> \n> Yuck; hiding the fact that you have an over-nested logic is not a way to\n> fix it.\n\nThis was accidental.\n\nBut well. Why bother with this, if this feature was rejected before already\nanyway.\n\nRudolf\n"},{"id":"131723","messageId":"alpine.DEB.1.00.1001151508550.3106@intel-tinevez-2-302","threadId":"22201","inReplyTo":"20100115134425.GA30986@rm.endoftheinternet.org","subject":"Re: [PATCH] git push --track","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-01-15T14:09:39Z","receivedAt":"2010-01-15T14:09:39Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 15 Jan 2010, Rudolf Polzer wrote:\n\n> On Fri, Jan 15, 2010 at 07:27:41AM +0900, Nanako Shiraishi wrote:\n> > 'git push --track' was suggested as a way to let users delay that decision.\n> > \n> > 'git branch --configure' to update the same information for an existing\n> > branch was suggested as an alternative UI. An added benefit is that this\n> > approach will allow the same option to be used when creating a branch.\n> > \n> > 'git pull --remember' that remembers the options used from the command line\n> > was suggested as a solution in addition to 'git branch --reconfigure'. Users\n> > can postpone the decision even more than 'git push --track', and it naturally\n> > supports setting branch.topic.rebase with 'git pull --rebase --remember'. It\n> > also has two additional benefits. 'push --track' configures what happens when\n> > you 'pull' (counter-intuitive), but 'pull --remember' makes 'pull' to change\n> > the setting used by 'pull' (much more natural). Also it does not add the\n> > confusing word 'track' to the interface (for a more detailed discussion on\n> > 'track', see http://article.gmane.org/gmane.comp.version-control.git/136785).\n\nThanks for the very nice summary!\n\n> Still requires you to specify the remote and the branch name twice.\n> \n> So the workflow would be:\n> \n> git push origin localbranch:remotebranch\n> ...\n> git pull --remember origin remotebranch:localbranch\n> \n> instead of\n> \n> git push --track origin localbranch:remotebranch\n> ...\n> git pull\n> \n> The one thing I want to avoid, is specifying the \"origin\n> localbranch:remotebranch\" stuff twice.\n> \n> Doesn't make git pull --remember a bad idea, it's good in many other \n> cases. But in my specific use case, git push --track is the most useful \n> one.\n\nThe thing is: done right, the three can share the major part of the code.\n\nCiao,\nDscho\n"},{"id":"131728","messageId":"87d41bl6bs.fsf@catnip.gol.com","threadId":"22201","inReplyTo":"20100115140048.GB30986@rm.endoftheinternet.org","subject":"Re: [PATCH] git push --track","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-01-15T15:45:59Z","receivedAt":"2010-01-15T15:45:59Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Rudolf Polzer writes:\n> But well. Why bother with this, if this feature was rejected before already\n> anyway.\n\nIt's a good feature and people obviously want it, so it's worth trying.\n\nSometimes it takes a few tries to get a feature added...\n\n-Miles\n\n-- \n`...the Soviet Union was sliding in to an economic collapse so comprehensive\n that in the end its factories produced not goods but bads: finished products\n less valuable than the raw materials they were made from.' [The Economist]\n"},{"id":"131742","messageId":"7vmy0f1bf6.fsf@alter.siamese.dyndns.org","threadId":"22201","inReplyTo":"20100115140048.GB30986@rm.endoftheinternet.org","subject":"Re: [PATCH] git push --track","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-15T18:16:13Z","receivedAt":"2010-01-15T18:16:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rudolf Polzer writes:\n\n> On Thu, Jan 14, 2010 at 09:47:22PM -0800, Junio C Hamano wrote:\n>> I have a feeling that it is more appropriate to have the additional code\n>> in transport_push(), which gets ls-remote information, runs match_refs()\n>> and finally calls transport->push_refs(). I think the extra branch\n>> configuration would fit better inside the if block immediately after all\n>> that happens, i.e.\n>> \n>> \tif (!(flags & TRANSPORT_PUSH_DRY_RUN)) {\n>> \t\tstruct ref *ref;\n>> \t\tfor (ref = remote_refs; ref; ref = ref->next)\n>> \t\t\tupdate_tracking_ref(transport->remote, ref, verbose);\n>> +\t\tif (flags & TRANSPORT_PUSH_RECONFIGURE_FORK)\n>> +\t\t\tconfigure_forked_branch(...);\n>> \t}\n>> \n>> in transport.c\n>\n> I thought about this place when making my patch, but didn't put it there\n> because this function is not called in the rsync protocol (which defines\n> transport->push).\n\nThat's not a very good reasoning. Instead of punishing well behaved\ntransport that defines push_ref, punish _only_ the transports that does\nnot define it (see the paragraph at the end of this message).\n\n> But well. Why bother with this, if this feature was rejected before already\n> anyway.\n\nRead the thread Nana quoted for you again; I nor anybody ever _rejected_\nthe ultimate goal, even though I said that the justifications were not\nsufficiently convincing for the previous implementation attempts.\n\nI think Ilari's patch is done right and can be extended by anybody who\ncares about rsync transport to call an extra ls-remote in the \"does this\none lack push_ref but know how to push\" codepath.\n"},{"id":"131745","messageId":"7vska7z0yp.fsf@alter.siamese.dyndns.org","threadId":"22201","inReplyTo":"87y6k06wgz.fsf@catnip.gol.com","subject":"Re: [PATCH] git push --track","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-15T18:18:06Z","receivedAt":"2010-01-15T18:18:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader writes:\n\n>> And it doesn't add --track to the UI.\n>\n> That's not a positive...\n\nOh, that is definitely a *HUGE* plus. I wouldn't go so far as to say that\nthe word --track was a mistake. But the thing is, unfortunately it has\nalready been contaminated by people using it in two completely different\nways and ended up confusing new people. Some use it to mean \"this branch\nforked off of and builds on top of\", and others use it to mean \"this ref\nholds a copy for reference purposes\".\n"},{"id":"131748","messageId":"fc339e4a1001151054y47fb7da3kdd6bbda8a3060d5@mail.gmail.com","threadId":"22201","inReplyTo":"7vska7z0yp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git push --track","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-01-15T18:54:49Z","receivedAt":"2010-01-15T18:54:49Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"On Sat, Jan 16, 2010 at 3:18 AM, Junio C Hamano wrote:\n>>> And it doesn't add --track to the UI.\n>>\n>> That's not a positive...\n>\n> Oh, that is definitely a *HUGE* plus.  I wouldn't go so far as to say that\n> the word --track was a mistake.  But the thing is, unfortunately it has\n> already been contaminated by people using it in two completely different\n> ways and ended up confusing new people.  Some use it to mean \"this branch\n> forked off of and builds on top of\", and others use it to mean \"this ref\n> holds a copy for reference purposes\".\n\nThen the right thing to do is to rename existing uses of --track so\nthat they're not confusing. Much-wanted functionality should not be\nrejected simply because of an earlier mistake which is essentially\northogonal to it, and which can be corrected easily enough.\n\nSo let's just say we're discussing the semantics, and it will use\nanother option name, which will be then retrofitted to other similar\nuses for consistency (as should surely be done regardless of what\nhappens with this command):\n\n git push --GRUBBLENUT\n\n-Miles\n\n-- \nDo not taunt Happy Fun Ball.\n"}]}