{"thread":{"id":"17434","subject":"[PATCH] push: Learn to set up branch tracking with '--track'","startedAt":"2009-01-29T13:38:43Z","lastAt":"2009-02-06T14:54:32Z","messageCount":15,"participants":["Johannes Schindelin","Sverre Rabbelier","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"102444","messageId":"alpine.DEB.1.00.0901291438030.3586@pacific.mpi-cbg.de","threadId":"17434","inReplyTo":"cover.1233236267u.git.johannes.schindelin@gmx.de","subject":"[PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-29T13:38:43Z","receivedAt":"2009-01-29T13:38:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"When pushing a branch to a remote repository that the remote side did\nnot know beforehand, it is often handy to set up the branch tracking\nsuch that\n\n\t$ git checkout xyz\n\t$ git push --track origin xyz:abc\n\t$ git pull\n\nwill pull the branch 'abc' from the remote 'origin' into the branch\n'xyz'.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tThis is a companion patch to the one I sent earlier:\n\n\thttp://article.gmane.org/gmane.comp.version-control.git/13735\n\n Documentation/git-push.txt | 7 ++++++-\n builtin-push.c | 42 ++++++++++++++++++++++++++++++++++++++++++\n t/t5516-fetch-push.sh | 11 +++++++++++\n 3 files changed, 59 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 7d1eced..fa1d54c 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -10,7 +10,7 @@ SYNOPSIS\n --------\n [verse]\n 'git push' [--all | --mirror] [--dry-run] [--tags] [--receive-pack=]\n-\t [--repo=] [-f | --force] [-v | --verbose]\n+\t [--repo=] [-f | --force] [-v | --verbose] [-t | --track]\n \t [ ...]\n \n DESCRIPTION\n@@ -126,6 +126,11 @@ useful if you write an alias or script around 'git-push'.\n \ttransfer spends extra cycles to minimize the number of\n \tobjects to be sent and meant to be used on slower connection.\n \n+-t::\n+--track::\n+\tSet up tracking information for the pushed branches, so that\n+\t'git pull' will remember the indicated mapping.\n+\n -v::\n --verbose::\n \tRun verbosely.\ndiff --git a/builtin-push.c b/builtin-push.c\nindex 122fdcf..9fd445d 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -16,6 +16,7 @@ static const char * const push_usage[] = {\n \n static int thin;\n static const char *receivepack;\n+static int track;\n \n static const char **refspec;\n static int refspec_nr;\n@@ -48,6 +49,41 @@ static void set_refspecs(const char **refs, int nr)\n \t}\n }\n \n+static void setup_tracking(const char *url)\n+{\n+\tstruct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;\n+\tint i;\n+\n+\tfor (i = 0; i < refspec_nr; i++) {\n+\t\tconst char *branch = refspec[i], *colon;\n+\n+\t\t/* skip non-branches */\n+\t\tif (!prefixcmp(\"refs/\", branch)) {\n+\t\t\tif (prefixcmp(\"refs/heads/\", branch))\n+\t\t\t\tcontinue;\n+\t\t\tbranch += strlen(\"refs/heads/\");\n+\t\t}\n+\t\tcolon = strchrnul(branch, ':');\n+\n+\t\tstrbuf_reset(&buf);\n+\t\tstrbuf_addf(&buf, \"branch.%.*s.remote\",\n+\t\t\t\t(int)(colon - branch), branch);\n+\t\tgit_config_set(buf.buf, url);\n+\n+\t\tstrbuf_reset(&buf);\n+\t\tstrbuf_addf(&buf, \"branch.%.*s.merge\",\n+\t\t\t\t(int)(colon - branch), branch);\n+\t\tstrbuf_reset(&buf2);\n+\t\tstrbuf_addf(&buf2, \"%s%s\",\n+\t\t\t*colon && !prefixcmp(\"refs/heads/\", colon + 1) ?\n+\t\t\t\"\" : \"refs/heads/\",\n+\t\t\t*colon ? colon + 1 : branch);\n+\t\tgit_config_set(buf.buf, buf2.buf);\n+\t}\n+\tstrbuf_release(&buf);\n+\tstrbuf_release(&buf2);\n+}\n+\n static int do_push(const char *repo, int flags)\n {\n \tint i, errs;\n@@ -96,6 +132,8 @@ static int do_push(const char *repo, int flags)\n \t\tif (flags & TRANSPORT_PUSH_VERBOSE)\n \t\t\tfprintf(stderr, \"Pushing to %s\\n\", remote->url[i]);\n \t\terr = transport_push(transport, refspec_nr, refspec, flags);\n+\t\tif (!err && track)\n+\t\t\tsetup_tracking(transport->url);\n \t\terr |= transport_disconnect(transport);\n \n \t\tif (!err)\n@@ -126,11 +164,15 @@ 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_BOOLEAN('t', \"track\", &track, \"set up branch tracking information\"),\n \t\tOPT_END()\n \t};\n \n \targc = parse_options(argc, argv, options, push_usage, 0);\n \n+\tif (track && !tags && !argc)\n+\t\tdie (\"Need explicit arguments for branch tracking\");\n+\n \tif (tags)\n \t\tadd_refspec(\"refs/tags/*\");\n \ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex 4426df9..e18b2f6 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -573,4 +573,15 @@ test_expect_success 'push with branches containing #' '\n \tgit checkout master\n '\n \n+test_expect_success 'push --track' '\n+\n+\tgit push --track testrepo master &&\n+\ttest ! -z \"$(git ls-remote testrepo master)\" &&\n+\ttest \"testrepo\" = $(git config branch.master.remote) &&\n+\ttest \"refs/heads/master\" = $(git config branch.master.merge) &&\n+\tgit push --track testrepo master:test &&\n+\ttest \"refs/heads/test\" = $(git config branch.master.merge)\n+\n+'\n+\n test_done\n-- \n1.6.1.1.506.gdbe181\n"},{"id":"102447","messageId":"bd6139dc0901290551g42ac7cb6m40194f75b8863be0@mail.gmail.com","threadId":"17434","inReplyTo":"alpine.DEB.1.00.0901291438030.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-29T13:51:15Z","receivedAt":"2009-01-29T13:51:15Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 29, 2009 at 12:45, Sverre Rabbelier wrote:\n> Mhhh, so maybe we want a way to set up tracking branches when pushing,\n> yes? From what I've seen a patch to do that shouldn't be too hard, so\n> if there's interest in that I could look into that.\n\nOn Thu, Jan 29, 2009 at 14:38, Johannes Schindelin\n wrote:\n> $ git checkout xyz\n> $ git push --track origin xyz:abc\n> $ git pull\n\nAm I reading this correctly in that you beat me to the patch I\nmentioned earlier in reply to Junio and Peff?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"102450","messageId":"alpine.DEB.1.00.0901291449150.3586@pacific.mpi-cbg.de","threadId":"17434","inReplyTo":"alpine.DEB.1.00.0901291438030.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-29T14:02:46Z","receivedAt":"2009-01-29T14:02:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 29 Jan 2009, Johannes Schindelin wrote:\n\n> \tThis is a companion patch to the one I sent earlier:\n> \n> \thttp://article.gmane.org/gmane.comp.version-control.git/13735\n\nHmm, maybe I should explain a little better.\n\nThat patch tried to make 'git pull' more convenient, that you could set up \ntracking information with a single flag to an explicit pull.\n\nThis patch does the same for 'git push', although I agree that the 'pull' \npatch should be done rather differently.\n\nCiao,\nDscho\n"},{"id":"102451","messageId":"alpine.DEB.1.00.0901291504080.3586@pacific.mpi-cbg.de","threadId":"17434","inReplyTo":"bd6139dc0901290551g42ac7cb6m40194f75b8863be0@mail.gmail.com","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-29T14:05:20Z","receivedAt":"2009-01-29T14:05:20Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 29 Jan 2009, Sverre Rabbelier wrote:\n\n> On Thu, Jan 29, 2009 at 12:45, Sverre Rabbelier wrote:\n> > Mhhh, so maybe we want a way to set up tracking branches when pushing,\n> > yes? From what I've seen a patch to do that shouldn't be too hard, so\n> > if there's interest in that I could look into that.\n> \n> On Thu, Jan 29, 2009 at 14:38, Johannes Schindelin\n> wrote:\n> > $ git checkout xyz\n> > $ git push --track origin xyz:abc\n> > $ git pull\n> \n> Am I reading this correctly in that you beat me to the patch I\n> mentioned earlier in reply to Junio and Peff?\n\nI have to admit that due to time constraints, I did not follow your \ndiscussion closely.\n\nI just just remembered that 'jast' mentioned something like this on IRC, \nand it seemed that it was easy to do. Now you go and point out all those \nmistakes in my code, okay?\n\nCiao,\nDscho\n"},{"id":"102513","messageId":"20090129223308.GB12871@coredump.intra.peff.net","threadId":"17434","inReplyTo":"alpine.DEB.1.00.0901291438030.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-29T22:33:08Z","receivedAt":"2009-01-29T22:33:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 29, 2009 at 02:38:43PM +0100, Johannes Schindelin wrote:\n\n> When pushing a branch to a remote repository that the remote side did\n> not know beforehand, it is often handy to set up the branch tracking\n> such that\n> \n> \t$ git checkout xyz\n> \t$ git push --track origin xyz:abc\n> \t$ git pull\n> \n> will pull the branch 'abc' from the remote 'origin' into the branch\n> 'xyz'.\n\nWhat if \"xyz\" is a tag? Right now, the patch generates a bogus config\nsection. Yes, you can say \"don't use --track, then\". But I can think two\nreasons why that isn't acceptable:\n\n 1. You might be pushing multiple things, one of which is a branch\n and one of which is not.\n\n 2. This is likely to grow a related config variable, similar to\n branch.autosetupmerge.\n\nHow about \"git push --track origin HEAD\"? This also generates bogus\nconfig. How about \"git push --track origin refs/heads/*:refs/heads/*\"?\nAlso bogus.\n\nIt looks like you catch \"git push --track --all\". So at least there is\nno bogus config generated. But it would be nice to translate this to\n\"create a tracking branch for everything I pushed\".\n\nSo I think this patch is going about it the wrong way. Instead of\nparsing the refspec, I think you actually want to look at what we _do_\npush (or at least try to push -- probably even uptodate refs should also\nhave tracking established), and use that. Then you will have wildcards\nexpanded, --all handled, etc. And I suspect all you have to do is\niterate over the result of match_refs (which we call later), which\nshould be even easier (because you don't have to parse the refspecs\nyourself). But I haven't looked carefully.\n\n> +\t\tif (!err && track)\n> +\t\t\tsetup_tracking(transport->url);\n\nWouldn't the remote name (if we have one) be preferable to the URL? As\nit is, doing \"git push --track origin master\" results in\n\n [branch \"master\"]\n remote = $YOUR_URL_FOR_ORIGIN\n merge = refs/heads/master\n\nwhich means that:\n\n 1. If you ever change remote.origin.url, it will not propagate to your\n branch section.\n\n 2. When you fetch, you are fetching into FETCH_HEAD, meaning your\n tracking refs are not updated.\n\n-Peff\n"},{"id":"102523","messageId":"20090129231715.GA17399@coredump.intra.peff.net","threadId":"17434","inReplyTo":"20090129223308.GB12871@coredump.intra.peff.net","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-29T23:17:15Z","receivedAt":"2009-01-29T23:17:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 29, 2009 at 05:33:08PM -0500, Jeff King wrote:\n\n> So I think this patch is going about it the wrong way. Instead of\n> parsing the refspec, I think you actually want to look at what we _do_\n> push (or at least try to push -- probably even uptodate refs should also\n> have tracking established), and use that. Then you will have wildcards\n> expanded, --all handled, etc. And I suspect all you have to do is\n> iterate over the result of match_refs (which we call later), which\n> should be even easier (because you don't have to parse the refspecs\n> yourself). But I haven't looked carefully.\n\nSomething like the patch below (which is obviously missing all of the\ninfrastructure for doing this optionally, but is meant to illustrate\nwhat I'm talking about).\n\nThe downside of this is that it only works for the git protocol\ntransport, making dumb push even more of a second class citizen (it\nlooks like this is already the case for updating tracking refs). But I\nthink this is the right place to do it, since we have detailed\ninformation on the matched refs. If other transports want to do the same\nthing, we should abstract setup_tracking (and update_tracking_ref while\nwe're at it) and call them from those transports.\n\n---\ndiff --git a/builtin-send-pack.c b/builtin-send-pack.c\nindex d65d019..23b326a 100644\n--- a/builtin-send-pack.c\n+++ b/builtin-send-pack.c\n@@ -247,6 +247,31 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)\n \t}\n }\n \n+static void setup_tracking(const char *remote, struct ref *ref)\n+{\n+\tconst char *name;\n+\tstruct strbuf key = STRBUF_INIT;\n+\n+\tif (ref->status != REF_STATUS_OK && ref->status != REF_STATUS_UPTODATE)\n+\t\treturn;\n+\tif (!ref->peer_ref)\n+\t\treturn;\n+\n+\tname = ref->peer_ref->name;\n+\tif (prefixcmp(name, \"refs/heads/\"))\n+\t\treturn;\n+\tname += 11;\n+\n+\tstrbuf_addf(&key, \"branch.%s.remote\", name);\n+\tgit_config_set(key.buf, remote);\n+\n+\tstrbuf_reset(&key);\n+\tstrbuf_addf(&key, \"branch.%s.merge\", name);\n+\tgit_config_set(key.buf, ref->name);\n+\n+\tstrbuf_release(&key);\n+}\n+\n static const char *prettify_ref(const struct ref *ref)\n {\n \tconst char *name = ref->name;\n@@ -523,6 +548,10 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest\n \t\tfor (ref = remote_refs; ref; ref = ref->next)\n \t\t\tupdate_tracking_ref(remote, ref);\n \t}\n+\tif (/* args.track && */ !args.dry_run) {\n+\t\tfor (ref = remote_refs; ref; ref = ref->next)\n+\t\t\tsetup_tracking(remote ? remote->name : dest, ref);\n+\t}\n \n \tif (!refs_pushed(remote_refs))\n \t\tfprintf(stderr, \"Everything up-to-date\\n\");\n"},{"id":"102530","messageId":"alpine.DEB.1.00.0901300127450.3586@pacific.mpi-cbg.de","threadId":"17434","inReplyTo":"20090129231715.GA17399@coredump.intra.peff.net","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-30T00:28:38Z","receivedAt":"2009-01-30T00:28:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 29 Jan 2009, Jeff King wrote:\n\n> On Thu, Jan 29, 2009 at 05:33:08PM -0500, Jeff King wrote:\n> \n> > So I think this patch is going about it the wrong way. Instead of\n> > parsing the refspec, I think you actually want to look at what we _do_\n> > push (or at least try to push -- probably even uptodate refs should also\n> > have tracking established), and use that. Then you will have wildcards\n> > expanded, --all handled, etc. And I suspect all you have to do is\n> > iterate over the result of match_refs (which we call later), which\n> > should be even easier (because you don't have to parse the refspecs\n> > yourself). But I haven't looked carefully.\n> \n> Something like the patch below (which is obviously missing all of the \n> infrastructure for doing this optionally, but is meant to illustrate \n> what I'm talking about).\n\nExcept that you miss http:// and rsync:// protocols. Those were the \nreasons I did not touch send-pack.\n\nCiao,\nDscho\n"},{"id":"102546","messageId":"20090130050925.GA18809@coredump.intra.peff.net","threadId":"17434","inReplyTo":"alpine.DEB.1.00.0901300127450.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-30T05:09:25Z","receivedAt":"2009-01-30T05:09:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 30, 2009 at 01:28:38AM +0100, Johannes Schindelin wrote:\n\n> > Something like the patch below (which is obviously missing all of the \n> > infrastructure for doing this optionally, but is meant to illustrate \n> > what I'm talking about).\n> \n> Except that you miss http:// and rsync:// protocols. Those were the \n> reasons I did not touch send-pack.\n\nYou didn't comment on the part of my email where I said exactly that,\nbut that I think this is still the right path forward.\n\nPushing through those protocols is sorely in need of update (actually,\nI thought rsync was all but dead at this point). But http push is\nmissing the update of tracking refs, the usual status output (it still\nhas the \"Maybe you are not up-to-date and need to pull first?\" message\nthat was removed from send-pack a year and a half ago), and who knows\nwhat other tweaks made to do_send_pack (which it appears to have been\ncopy-and-pasted from in 2006) in the last few years.\n\nSo either we don't care about http-push being consistent with send-pack,\nand it is OK to have this feature in one but not the other. Or we do,\nand we really need to clean up the current divergence.\n\n-Peff\n"},{"id":"102606","messageId":"alpine.DEB.1.00.0901301656290.3586@pacific.mpi-cbg.de","threadId":"17434","inReplyTo":"20090130050925.GA18809@coredump.intra.peff.net","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-30T15:58:25Z","receivedAt":"2009-01-30T15:58:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 30 Jan 2009, Jeff King wrote:\n\n> On Fri, Jan 30, 2009 at 01:28:38AM +0100, Johannes Schindelin wrote:\n> \n> > > Something like the patch below (which is obviously missing all of the \n> > > infrastructure for doing this optionally, but is meant to illustrate \n> > > what I'm talking about).\n> > \n> > Except that you miss http:// and rsync:// protocols. Those were the \n> > reasons I did not touch send-pack.\n> \n> You didn't comment on the part of my email where I said exactly that,\n> but that I think this is still the right path forward.\n> \n> Pushing through those protocols is sorely in need of update (actually,\n> I thought rsync was all but dead at this point). But http push is\n> missing the update of tracking refs, the usual status output (it still\n> has the \"Maybe you are not up-to-date and need to pull first?\" message\n> that was removed from send-pack a year and a half ago), and who knows\n> what other tweaks made to do_send_pack (which it appears to have been\n> copy-and-pasted from in 2006) in the last few years.\n> \n> So either we don't care about http-push being consistent with send-pack,\n> and it is OK to have this feature in one but not the other. Or we do,\n> and we really need to clean up the current divergence.\n\nI do not see how your patch to send-pack makes that divergence any \nbetter, or for that matter, keeps it as bad as it is.\n\nIn other words, if you want to give the other protocols at least a \n_chance_ to catch up, you definitely need the support for push --track in \nbuiltin-push.c or at least in transport.c.\n\nCiao,\nDscho\n"},{"id":"102615","messageId":"20090130162258.GA7065@sigill.intra.peff.net","threadId":"17434","inReplyTo":"alpine.DEB.1.00.0901301656290.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-30T16:22:58Z","receivedAt":"2009-01-30T16:22:58Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 30, 2009 at 04:58:25PM +0100, Johannes Schindelin wrote:\n\n> > So either we don't care about http-push being consistent with send-pack,\n> > and it is OK to have this feature in one but not the other. Or we do,\n> > and we really need to clean up the current divergence.\n> \n> I do not see how your patch to send-pack makes that divergence any \n> better, or for that matter, keeps it as bad as it is.\n\nNo, it makes it worse. My point was that I am not sure people actually\n_care_ that much about the divergence.\n\n> In other words, if you want to give the other protocols at least a \n> _chance_ to catch up, you definitely need the support for push --track in \n> builtin-push.c or at least in transport.c.\n\nBut neither of those places has the information to do it _right_. I\nthink the right thing to do is:\n\n 1. factor out \"generic\" routines from send-pack, including status\n output formatting and tracking ref updating\n\n 2. refactor http-push to use those routines, bringing it in line with\n send-pack\n\n 3. add --track support in the same generic way, and hook it from both\n transports\n\nI can try to work on this, but I'm not excited about major surgery to\nhttp-push, which I don't have a working test setup for. I can't bring\nmyself to care about refactoring rsync, given the recent deprecation\ndiscussion.\n\nIf it is going to be added to push or transport, then the transport API\nneeds refactoring to actually pass out information on what happened\n(specifically, how we expanded the refspecs into matching ref pairs).\nAnd maybe that is a more sensible long-term solution, but it is going\ninvolve a lot of changes, too.\n\n-Peff\n"},{"id":"102625","messageId":"alpine.DEB.1.00.0901301804030.3586@pacific.mpi-cbg.de","threadId":"17434","inReplyTo":"20090130162258.GA7065@sigill.intra.peff.net","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-30T17:05:30Z","receivedAt":"2009-01-30T17:05:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 30 Jan 2009, Jeff King wrote:\n\n> I think the right thing to do is:\n> \n> 1. factor out \"generic\" routines from send-pack, including status\n> output formatting and tracking ref updating\n> \n> 2. refactor http-push to use those routines, bringing it in line with\n> send-pack\n> \n> 3. add --track support in the same generic way, and hook it from both\n> transports\n\nNow we're thinking along the same lines!\n\n> I can try to work on this, but I'm not excited about major surgery to \n> http-push, which I don't have a working test setup for.\n\nYou don't have an apache installed?\n\n> I can't bring myself to care about refactoring rsync, given the recent \n> deprecation discussion.\n\nDon't do it, then.\n\n> If it is going to be added to push or transport, then the transport API \n> needs refactoring to actually pass out information on what happened \n> (specifically, how we expanded the refspecs into matching ref pairs). \n> And maybe that is a more sensible long-term solution, but it is going \n> involve a lot of changes, too.\n\nI think that the --track should just be passed to the transport API, which \nshould call the necessary git_config thing itself upon successful push.\n\nCiao,\nDscho\n"},{"id":"102855","messageId":"20090202131611.GB8487@sigio.peff.net","threadId":"17434","inReplyTo":"alpine.DEB.1.00.0901301804030.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-02T13:16:11Z","receivedAt":"2009-02-02T13:16:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 30, 2009 at 06:05:30PM +0100, Johannes Schindelin wrote:\n\n> > I think the right thing to do is:\n> > \n> > 1. factor out \"generic\" routines from send-pack, including status\n> > output formatting and tracking ref updating\n> > \n> > 2. refactor http-push to use those routines, bringing it in line with\n> > send-pack\n> > \n> > 3. add --track support in the same generic way, and hook it from both\n> > transports\n> \n> Now we're thinking along the same lines!\n\nOK, good.\n\n> > I can try to work on this, but I'm not excited about major surgery to \n> > http-push, which I don't have a working test setup for.\n> \n> You don't have an apache installed?\n\nNo, though \"apt-get install apache\" is easy enough. I was more concerned\nabout wading through the mess of apache configuration to turn on webdave\nsupport. But that is just my empty grumbling and complaining; it's not a\nreal stumbling block to doing this patch.\n\nAnd when I wrote that, I was fully intending to pick up this topic and\nwork on the steps outlined above.\n\n_But_.\n\nIt looks like the consensus is to add a branch.master config section\neven when cloning an empty repo. And that should address my concern in\nthe 99% of cases where people use the default \"master\" setup. Which kind\nof takes away the main use case for this topic.\n\nSo it doesn't make much sense to me to put effort into it now. The\nhttp-push cleanups might be nice for http-push users, but I don't\nremember even seeing a single user request or complaint about it. So I\nam not too keen to go cleaning up code that _I_ don't care about, and\nthat I am not sure anyone _else_ even cares about.\n\n-Peff\n"},{"id":"102860","messageId":"alpine.DEB.1.00.0902021449370.3586@pacific.mpi-cbg.de","threadId":"17434","inReplyTo":"20090202131611.GB8487@sigio.peff.net","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-02T13:52:26Z","receivedAt":"2009-02-02T13:52:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 2 Feb 2009, Jeff King wrote:\n\n> It looks like the consensus is to add a branch.master config section \n> even when cloning an empty repo. And that should address my concern in \n> the 99% of cases where people use the default \"master\" setup. Which kind \n> of takes away the main use case for this topic.\n\n>From where I sit, the main use would have been:\n\n\t# \n\t$ git init\n\t$ git add .\n\t$ git commit -m initial\\ revision\n\t# \n\t# \n\t$ git remote add origin $URL\n\t$ git push -t origin master\n\nBTW I always wondered if it would make sense to introduce \"git commit \n--init\" for the first 3 Git commands. I use them way too often.\n\nAh, well, I will install an alias on all of my machines.\n\nCiao,\nDscho\n"},{"id":"103482","messageId":"20090206141000.GC18364@coredump.intra.peff.net","threadId":"17434","inReplyTo":"alpine.DEB.1.00.0902021449370.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-06T14:10:00Z","receivedAt":"2009-02-06T14:10:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 02, 2009 at 02:52:26PM +0100, Johannes Schindelin wrote:\n\n> > It looks like the consensus is to add a branch.master config section \n> > even when cloning an empty repo. And that should address my concern in \n> > the 99% of cases where people use the default \"master\" setup. Which kind \n> > of takes away the main use case for this topic.\n> \n> From where I sit, the main use would have been:\n> \n> \t# \n> \t$ git init\n> \t$ git add .\n> \t$ git commit -m initial\\ revision\n> \t# \n> \t# \n> \t$ git remote add origin $URL\n> \t$ git push -t origin master\n\nHmm. True. The \"clone empty\" fix only affects people who use the \"init;\nclone empty; push\" method. Push-tracking would work for the\n\"traditional\" method you outline above.\n\nSo probably it is worth doing the steps I described earlier. I'll throw\nit on my todo list, but the priority is not especially high.\n\n> BTW I always wondered if it would make sense to introduce \"git commit \n> --init\" for the first 3 Git commands. I use them way too often.\n\nI have noticed that, too, but I think it is because I am constantly\ncreating test repos to debug git. Regular users don't have the same\nproblem. :)\n\n-Peff\n"},{"id":"103494","messageId":"alpine.DEB.1.00.0902061552320.7377@intel-tinevez-2-302","threadId":"17434","inReplyTo":"20090206141000.GC18364@coredump.intra.peff.net","subject":"Re: [PATCH] push: Learn to set up branch tracking with '--track'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-06T14:54:32Z","receivedAt":"2009-02-06T14:54:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 6 Feb 2009, Jeff King wrote:\n\n> > BTW I always wondered if it would make sense to introduce \"git commit \n> > --init\" for the first 3 Git commands. I use them way too often.\n> \n> I have noticed that, too, but I think it is because I am constantly\n> creating test repos to debug git. Regular users don't have the same\n> problem. :)\n\nI do not do that for test repositories, but for untarred 3rd party \nprojects, such as zlib.\n\n\t$ tar xvf $TAR\n\t$ cd $DIR\n\t$ git init\n\t$ git add .\n\t$ git commit -m initial\n\t\n\t\n\nCiao,\nDscho\n"}]}