{"thread":{"id":"8173","subject":"pull/push inconsistencies","startedAt":"2007-05-15T22:53:11Z","lastAt":"2007-05-16T22:35:27Z","messageCount":11,"participants":["Martin Langhoff","Jakub Narebski","Junio C Hamano","J. Bruce Fields","Daniel Barkalow","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"42258","messageId":"46a038f90705151553h553ae9d3kc3d43af72f385a42@mail.gmail.com","threadId":"8173","inReplyTo":null,"subject":"pull/push inconsistencies","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-05-15T22:53:11Z","receivedAt":"2007-05-15T22:53:11Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"I am noticing some UI inconsistencies with pull/push. Not sure where\nthey are -- and quite busy atm -- if they are in bash I might be able\nto hunt them down and fix. In case anyone else cares...\n\n--\n\nWhen tracking several branches from a repo, git-pull does a fetch (of\nall the remote heads) and merges _only the tracking branch currently\nchecked out_. That's ok. However, if I checkout another tracking\nbranch and issue git-pull, the merge does not happen because git-fetch\nfinds nothing new on the remote side. git-pull should merge anyway if\nremotes/origin/ is ahead of the local head.\n\nThe workaround is to call git-merge explicitly, but git-pull is\nmisleading the user saying \"nothing to merge\" instead of completing\nthe merge.\n\n--\n\nMy second issue is that git-push does not update\nremotes// so if I do git-push && gitk --all it looks\nas if I haven't pushed. Misleading again. :-/\n\n--\n\nThird issue - if I do\n\n # we start with a cloned repo that is in sync with\n # its \"origin\" repo. No local commits to speak of...\n # git-fetch brings updates to 3 remote branches - none affecting the current\n # checked out branch...\n git-fetch\n git-commit some/path\n git-push\n\nthe output of git-push will show _4_ branches being pushed. For some\nreason git-push says that it's pushing remotes/origin/branchname ->\norigin/branchname for all the branches fetched recently -- and not\nmodified! I expect only _1_ branch to be named during push - the only\none.\n\n\nNone of the above are showstoppers, but the user feedback of these\ncommands - the very core workflow for beginners - is quite confusing.\nI know how to check that things are correct in spite of the messages,\nand by now I trust git internals to do the right thing. But newcomers\nare getting some frights over here...\n\ncheers,\n\n\n\nmartin\n"},{"id":"42261","messageId":"f2df9a$so6$1@sea.gmane.org","threadId":"8173","inReplyTo":"46a038f90705151553h553ae9d3kc3d43af72f385a42@mail.gmail.com","subject":"Re: pull/push inconsistencies","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-15T23:21:16Z","receivedAt":"2007-05-15T23:21:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Martin Langhoff wrote:\n\n> When tracking several branches from a repo, git-pull does a fetch (of\n> all the remote heads) and merges _only the tracking branch currently\n> checked out_. That's ok. However, if I checkout another tracking\n> branch and issue git-pull, the merge does not happen because git-fetch\n> finds nothing new on the remote side. git-pull should merge anyway if\n> remotes/origin/ is ahead of the local head.\n> \n> The workaround is to call git-merge explicitly, but git-pull is\n> misleading the user saying \"nothing to merge\" instead of completing\n> the merge.\n\nStrange. This would be regression, but in my experience \"git pull\" _always_\nmerges, even if there is nothing to fetch. But I don't have branch to merge\nconfigured...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"42270","messageId":"7vtzudhayr.fsf@assigned-by-dhcp.cox.net","threadId":"8173","inReplyTo":"46a038f90705151553h553ae9d3kc3d43af72f385a42@mail.gmail.com","subject":"Re: pull/push inconsistencies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-16T00:24:28Z","receivedAt":"2007-05-16T00:24:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" writes:\n\n> I am noticing some UI inconsistencies with pull/push. Not sure where\n> they are -- and quite busy atm -- if they are in bash I might be able\n> to hunt them down and fix. In case anyone else cares...\n>\n> --\n>\n> When tracking several branches from a repo, git-pull does a fetch (of\n> all the remote heads) and merges _only the tracking branch currently\n> checked out_. That's ok. However, if I checkout another tracking\n> branch and issue git-pull, the merge does not happen because git-fetch\n> finds nothing new on the remote side. git-pull should merge anyway if\n> remotes/origin/ is ahead of the local head.\n\nThat's my expectation and I am a bit surprised if it doesn't.\n\n> My second issue is that git-push does not update\n> remotes// so if I do git-push && gitk --all it looks\n> as if I haven't pushed. Misleading again. :-/\n\nThe standard answer is not to push into a live repository\nwithout understanding what you are doing.\n\nI've been debating this myself, but I do not think of a good\ncanned configuration to satisfy different workflows.\n\n - Central repository setup a la CVS would want to:\n\n\t$ git clone $remote\n\n would create\n\n\t[remote \"origin\"]\n \turl = $remote\n pull = refs/heads/*:refs/remotes/origin/*\n\n and would want to rely on the \"only-fast-forward\" safety to\n push into the corresonding branch.\n\n\t$ git push\n\n would push only corresponding branch, so there is no need for\n configuration.\n\n However, this is usually good only for the CVS-style shared\n central bare repository.\n\n - When using multiple private repositories, hopping between\n mothership and satellite, often the arrangement to allow\n fetch and push be symmetrical is desired:\n\n\tsatellite$ git clone $mothership\n\n would create:\n\n \t[remote \"origin\"]\n \turl = $mothership\n pull = refs/heads/*:refs/remotes/origin/*\n\n on the satellite. But if mothership could push into\n satellite, you would also want to have\n\n\t[remote \"satellite\"]\n url = $satellite\n push = refs/heads/*:refs/remotes/origin/*\n\n to make \"git push satellite\" run on mothership and \"git fetch\n origin\" run on satellite be equivalent.\n\n In this workflow, it is clear that a push from the mothership\n alone would not affect the working tree of the satellite; in\n fact, pushing into tracking branches from the mothership is\n arranged to mirror fetching into tracking branches from the\n satellite, with the explicit purpose of not affecting the\n working tree of the satellite, so there is less room for\n confusion.\n\n However, we cannot make this the default, which would break\n the traditional CVS-style shared central repository\n\n - A developer who publishes to his public distribution point\n (bare):\n\n\tpublic$ git clone --bare $my_private_repo\n\n private$ git push $public\n\n This pushes the matching refs between the two, which is the\n right thing, without any configuration. You would not\n accidentally publish newly created throwaway branches you\n used while working inside the private repository.\n\nUnfortunately, historically \"git-push\" was publisher's tool (the\nlast workflow was the primary target). Later central bare\nrepository support was also documented. The second workflow is\nnot very well supported.\n\nAnd pushing into live repository using 'matching refs' is almost\nalways a mistake, unless the user knows what he is doing.\n\n> Third issue - if I do\n>\n> # we start with a cloned repo that is in sync with\n> # its \"origin\" repo. No local commits to speak of...\n> # git-fetch brings updates to 3 remote branches - none affecting the current\n> # checked out branch...\n> git-fetch\n> git-commit some/path\n> git-push\n>\n> the output of git-push will show _4_ branches being pushed. For some\n> reason git-push says that it's pushing remotes/origin/branchname ->\n> origin/branchname for all the branches fetched recently -- and not\n> modified! I expect only _1_ branch to be named during push - the only\n> one.\n\ngit-push without parameters and configuration pushes matching\nbranches. This has been true from day one. Again, I think we\nshould be able to make this safer so that \"git-push\" in cloned\nrepository would do something more restricted (perhaps limiting\nto refs/heads?), but I do not think of a universally acceptable\ncanned configuration.\n\n> None of the above are showstoppers, but the user feedback of these\n> commands - the very core workflow for beginners - is quite confusing.\n\nYes, git is distributed and perhaps the expectation to be able\nto \"git push\" without saying where to and what to push is coming\nfrom some centralized system mindset. If somehow we can disable\n\"git push\" before a sensible refspecs are configured, that would\nbe an improvement for new users, but the \"push matching refs\"\nbehaviour is very handy for already established workflows of\npeople who publish things.\n\nWhen pushing into your public distribution point, which does\n_NOT_ have remotes/* hierarchy by definition, what will match\nbetween your private working repository and your public\ndistribution point are heads/ and tags/ and all goes well. You\ndo not want to accidentally push your new throwaway branches.\n"},{"id":"42277","messageId":"46a038f90705151811o2159aa5ai84a13e77e790e376@mail.gmail.com","threadId":"8173","inReplyTo":"7vtzudhayr.fsf@assigned-by-dhcp.cox.net","subject":"Re: pull/push inconsistencies","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-05-16T01:11:02Z","receivedAt":"2007-05-16T01:11:02Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/16/07, Junio C Hamano wrote:\n> \"Martin Langhoff\" writes:\n> > When tracking several branches from a repo, git-pull does a fetch (of\n> > all the remote heads) and merges _only the tracking branch currently\n> > checked out_. That's ok. However, if I checkout another tracking\n> > branch and issue git-pull, the merge does not happen because git-fetch\n> > finds nothing new on the remote side. git-pull should merge anyway if\n> > remotes/origin/ is ahead of the local head.\n>\n> That's my expectation and I am a bit surprised if it doesn't.\n\nI'll try get a repro script then.\n\n> > My second issue is that git-push does not update\n> > remotes// so if I do git-push && gitk --all it looks\n> > as if I haven't pushed. Misleading again. :-/\n>\n> The standard answer is not to push into a live repository\n> without understanding what you are doing.\n\nI don't quite understand that statement. I think I know what I am\ndoing: telling git-push to push new commits from matching local refs\nto remote refs safely (only ff, unless there's a + in the\nconfiguration for that head).\n\nWhy can't git match that the remote is the remote in .git/refs/remotes\nand put the right data SHA1 in .git/refs/remotes/?\n\n...\n\n> And pushing into live repository using 'matching refs' is almost\n> always a mistake, unless the user knows what he is doing.\n\nHey - I'm only using it because you've recommended it as a migration\npath! ;-) Combined with tracking branches, it works great.\n\n> > Third issue - if I do\n> >\n> > # we start with a cloned repo that is in sync with\n> > # its \"origin\" repo. No local commits to speak of...\n> > # git-fetch brings updates to 3 remote branches - none affecting the current\n> > # checked out branch...\n> > git-fetch\n> > git-commit some/path\n> > git-push\n> >\n> > the output of git-push will show _4_ branches being pushed. For some\n> > reason git-push says that it's pushing remotes/origin/branchname ->\n> > origin/branchname for all the branches fetched recently -- and not\n> > modified! I expect only _1_ branch to be named during push - the only\n> > one.\n>\n> git-push without parameters and configuration pushes matching\n> branches. This has been true from day one. Again, I think we\n> should be able to make this safer so that \"git-push\" in cloned\n> repository would do something more restricted (perhaps limiting\n> to refs/heads?), but I do not think of a universally acceptable\n> canned configuration.\n\nThere are 2 things that I see as wrong...\n - local .git/refs/remote/origin/foo and refs/heads/foo match - why is\ngit-push talking about updating them?\n - matching refs should ignore .git/refs/remote\n\nBut perhaps I'm naive in thinking that the 'matching refs' thing will\nignore the local .git/refs/remotes directory. AFAICS it's the only\nsane thing to do.\n\ncheers,\n\n\nmartin\n"},{"id":"42278","messageId":"7v646th8a2.fsf@assigned-by-dhcp.cox.net","threadId":"8173","inReplyTo":"46a038f90705151811o2159aa5ai84a13e77e790e376@mail.gmail.com","subject":"Re: pull/push inconsistencies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-16T01:22:29Z","receivedAt":"2007-05-16T01:22:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" writes:\n\n> There are 2 things that I see as wrong...\n> - local .git/refs/remote/origin/foo and refs/heads/foo match - why is\n> git-push talking about updating them?\n\nOoo...\n\nDo you mean if you have refs/remotes/origin/foo locally, and\npush into a repository that has refs/heads/foo (but not\nrefs/remotes/origin/foo), the push results in refs/heads/foo\ngetting updated? If that is what is happening (without any\nrefspecs to instruct git-push to do so) that sounds quite buggy.\nI need to look into the code for this one.\n\nAnd I think earlier one I was confused that I thought you were\ntalking about pushing into refs/heads/branch (where branch is\nchecked out). Sorry.\n\n> - matching refs should ignore .git/refs/remote\n>\n> ... the 'matching refs' thing will\n> ignore the local .git/refs/remotes directory. AFAICS it's the only\n> sane thing to do.\n\nI think you are probably right in that matching only heads and\nperhaps tags is a sane thing to do (even tags/ is debatable, as\nthey are supposed to be immutable by convention). As a matter\nof fact I do not recall which part of refs/ namespace it looks\nat, but it is a very old part of the system and I would not be\nsurprised if it silently assumed that there are only heads and\ntags there (and not explicitly matching heads and tags only).\n"},{"id":"42279","messageId":"20070516014002.GA8062@fieldses.org","threadId":"8173","inReplyTo":"7v646th8a2.fsf@assigned-by-dhcp.cox.net","subject":"Re: pull/push inconsistencies","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-16T01:40:02Z","receivedAt":"2007-05-16T01:40:02Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, May 15, 2007 at 06:22:29PM -0700, Junio C Hamano wrote:\n> \"Martin Langhoff\" writes:\n> \n> > There are 2 things that I see as wrong...\n> > - local .git/refs/remote/origin/foo and refs/heads/foo match - why is\n> > git-push talking about updating them?\n> \n> Ooo...\n> \n> Do you mean if you have refs/remotes/origin/foo locally, and\n> push into a repository that has refs/heads/foo (but not\n> refs/remotes/origin/foo), the push results in refs/heads/foo\n> getting updated? If that is what is happening (without any\n> refspecs to instruct git-push to do so) that sounds quite buggy.\n> I need to look into the code for this one.\n\nI understand him to be saying that it *doesn't* do that, and that he\n*wants* it to.\n\nPeople think of refs/remotes/origin as a cache of the origin\nrepository's branch heads, and they expect it to be updated on write\n(push) as well as read (fetch).\n\n--b.\n"},{"id":"42280","messageId":"46a038f90705151851i9027e01x993300b1b50d0285@mail.gmail.com","threadId":"8173","inReplyTo":"20070516014002.GA8062@fieldses.org","subject":"Re: pull/push inconsistencies","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-05-16T01:51:47Z","receivedAt":"2007-05-16T01:51:47Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/16/07, J. Bruce Fields wrote:\n> On Tue, May 15, 2007 at 06:22:29PM -0700, Junio C Hamano wrote:\n> > \"Martin Langhoff\" writes:\n> >\n> > > There are 2 things that I see as wrong...\n> > > - local .git/refs/remote/origin/foo and refs/heads/foo match - why is\n> > > git-push talking about updating them?\n> >\n> > Ooo...\n> >\n> > Do you mean if you have refs/remotes/origin/foo locally, and\n> > push into a repository that has refs/heads/foo (but not\n> > refs/remotes/origin/foo), the push results in refs/heads/foo\n> > getting updated? If that is what is happening (without any\n> > refspecs to instruct git-push to do so) that sounds quite buggy.\n> > I need to look into the code for this one.\n>\n> I understand him to be saying that it *doesn't* do that, and that he\n> *wants* it to.\n\nI'm probably in a bad-communication day :-/\n\nI have locally .git/refs/remotes/origin/foo, and the remote repo has\nrefs/heads/foo. I don't have .git/refs/heads/foo in this case. When I\ndo git-push, it doesn't really change the remote repo, but it _tells_\nme it has.\n\nSo - behaviour-wise, it's fine. It's not changing the remote repo. But\nit tells me it does. It's just plain weird and misleading...\n\n> People think of refs/remotes/origin as a cache of the origin\n> repository's branch heads, and they expect it to be updated on write\n> (push) as well as read (fetch).\n\nYes ;-)\n\ncheers,\n\n\nmartin\n"},{"id":"42281","messageId":"7vy7jpfqki.fsf@assigned-by-dhcp.cox.net","threadId":"8173","inReplyTo":"46a038f90705151851i9027e01x993300b1b50d0285@mail.gmail.com","subject":"Re: pull/push inconsistencies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-16T02:30:21Z","receivedAt":"2007-05-16T02:30:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" writes:\n\n>> I understand him to be saying that it *doesn't* do that, and that he\n>> *wants* it to.\n>\n> I'm probably in a bad-communication day :-/\n\nSorry, I think I am lacking my medication :-/\n\n> I have locally .git/refs/remotes/origin/foo, and the remote repo has\n> refs/heads/foo. I don't have .git/refs/heads/foo in this case. When I\n> do git-push, it doesn't really change the remote repo, but it _tells_\n> me it has.\n>\n> So - behaviour-wise, it's fine. It's not changing the remote repo. But\n> it tells me it does. It's just plain weird and misleading...\n\nI would agree with that it is misleading or plain wrong if it\nsays it updated something that it didn't.\n\n>> People think of refs/remotes/origin as a cache of the origin\n>> repository's branch heads, and they expect it to be updated on write\n>> (push) as well as read (fetch).\n>\n> Yes ;-)\n\nOn a related note, I think recent series from Daniel, parked in\n'pu' while 1.5.2 is prepared, contained a new feature to update\nthe refs/remotes/origin/* on the pushing repository after\ngit-push, to save one round of fetch (that is, pretend that you\nfetched immediately after you pushed).\n"},{"id":"42282","messageId":"Pine.LNX.4.64.0705152214580.18541@iabervon.org","threadId":"8173","inReplyTo":"46a038f90705151553h553ae9d3kc3d43af72f385a42@mail.gmail.com","subject":"[PATCH] Re: pull/push inconsistencies","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-05-16T02:50:19Z","receivedAt":"2007-05-16T02:50:19Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 16 May 2007, Martin Langhoff wrote:\n\n> My second issue is that git-push does not update\n> remotes// so if I do git-push && gitk --all it looks\n> as if I haven't pushed. Misleading again. :-/\n\nThis patch is based on my \"remote\" series, currently in \"pu\". I'm not 100% \nsure that this is the right behavior for the case where the change isn't a \nfast-forward; if the push worked, it just assumes that you don't care if \nthe tracking ref would be rewound, even if the fetch wouldn't force it.\nIn this case, you must have rewound your head, and forced the push, so \nit's implausible that you want the tracking ref to go strictly forward \nwhen you've made the source of the ref rewind.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n---- cut here ----\nUpdate local tracking refs when pushing\n\nThis also adds a --remote option to send-pack, which specifies the\nconfigured remote being used. It is provided automatically by\ngit-push, and must match the url (which is still needed, since there\ncould be multiple urls).\n\nSigned-off-by: Daniel Barkalow \n---\n builtin-push.c | 9 +++++++--\n send-pack.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++---------\n 2 files changed, 53 insertions(+), 11 deletions(-)\n\ndiff --git a/builtin-push.c b/builtin-push.c\nindex 0e602f3..6084899 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -178,8 +178,13 @@ static int do_push(const char *repo)\n \t\tif (!prefixcmp(dest, \"http://\") ||\n \t\t !prefixcmp(dest, \"https://\"))\n \t\t\tsender = \"http-push\";\n-\t\telse if (thin)\n-\t\t\targv[dest_argc++] = \"--thin\";\n+\t\telse {\n+\t\t\tchar *rem = xmalloc(strlen(remote->name) + 10);\n+\t\t\tsprintf(rem, \"--remote=%s\", remote->name);\n+\t\t\targv[dest_argc++] = rem;\n+\t\t\tif (thin)\n+\t\t\t\targv[dest_argc++] = \"--thin\";\n+\t\t}\n \t\targv[0] = sender;\n \t\targv[dest_argc++] = dest;\n \t\twhile (dest_refspec_nr--)\ndiff --git a/send-pack.c b/send-pack.c\nindex 6851043..eabadbe 100644\n--- a/send-pack.c\n+++ b/send-pack.c\n@@ -177,7 +177,7 @@ static int receive_status(int in)\n \treturn ret;\n }\n \n-static int send_pack(int in, int out, int nr_refspec, char **refspec)\n+static int send_pack(int in, int out, struct remote *remote, int nr_refspec, char **refspec)\n {\n \tstruct ref *ref;\n \tint new_refs;\n@@ -214,18 +214,19 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)\n \tnew_refs = 0;\n \tfor (ref = remote_refs; ref; ref = ref->next) {\n \t\tchar old_hex[60], *new_hex;\n-\t\tint delete_ref;\n+\t\tint will_delete_ref;\n \n \t\tif (!ref->peer_ref)\n \t\t\tcontinue;\n \n-\t\tdelete_ref = is_null_sha1(ref->peer_ref->new_sha1);\n-\t\tif (delete_ref && !allow_deleting_refs) {\n+\n+\t\twill_delete_ref = is_null_sha1(ref->peer_ref->new_sha1);\n+\t\tif (will_delete_ref && !allow_deleting_refs) {\n \t\t\terror(\"remote does not support deleting refs\");\n \t\t\tret = -2;\n \t\t\tcontinue;\n \t\t}\n-\t\tif (!delete_ref &&\n+\t\tif (!will_delete_ref &&\n \t\t !hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {\n \t\t\tif (verbose)\n \t\t\t\tfprintf(stderr, \"'%s': up-to-date\\n\", ref->name);\n@@ -252,7 +253,7 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)\n \t\t */\n \n \t\tif (!force_update &&\n-\t\t !delete_ref &&\n+\t\t !will_delete_ref &&\n \t\t !is_null_sha1(ref->old_sha1) &&\n \t\t !ref->force) {\n \t\t\tif (!has_sha1_file(ref->old_sha1) ||\n@@ -276,7 +277,7 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)\n \t\t\t}\n \t\t}\n \t\thashcpy(ref->new_sha1, ref->peer_ref->new_sha1);\n-\t\tif (!delete_ref)\n+\t\tif (!will_delete_ref)\n \t\t\tnew_refs++;\n \t\tstrcpy(old_hex, sha1_to_hex(ref->old_sha1));\n \t\tnew_hex = sha1_to_hex(ref->new_sha1);\n@@ -291,7 +292,7 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)\n \t\telse\n \t\t\tpacket_write(out, \"%s %s %s\",\n \t\t\t\t old_hex, new_hex, ref->name);\n-\t\tif (delete_ref)\n+\t\tif (will_delete_ref)\n \t\t\tfprintf(stderr, \"deleting '%s'\\n\", ref->name);\n \t\telse {\n \t\t\tfprintf(stderr, \"updating '%s'\", ref->name);\n@@ -301,6 +302,28 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)\n \t\t\tfprintf(stderr, \"\\n from %s\\n to %s\\n\",\n \t\t\t\told_hex, new_hex);\n \t\t}\n+\t\tif (remote) {\n+\t\t\tstruct refspec rs;\n+\t\t\trs.src = ref->name;\n+\t\t\tremote_find_tracking(remote, &rs);\n+\t\t\tif (rs.dst) {\n+\t\t\t\tstruct ref_lock *lock;\n+\t\t\t\tfprintf(stderr, \" Also local %s\\n\", rs.dst);\n+\t\t\t\tif (will_delete_ref) {\n+\t\t\t\t\tif (delete_ref(rs.dst, NULL)) {\n+\t\t\t\t\t\terror(\"Failed to delete\");\n+\t\t\t\t\t}\n+\t\t\t\t} else {\n+\t\t\t\t\tlock = lock_any_ref_for_update(rs.dst, NULL);\n+\t\t\t\t\tif (!lock)\n+\t\t\t\t\t\terror(\"Failed to lock\");\n+\t\t\t\t\telse\n+\t\t\t\t\t\twrite_ref_sha1(lock, ref->new_sha1,\n+\t\t\t\t\t\t\t \"update by push\");\n+\t\t\t\t}\n+\t\t\t\tfree(rs.dst);\n+\t\t\t}\n+\t\t}\n \t}\n \n \tpacket_flush(out);\n@@ -345,6 +368,8 @@ int main(int argc, char **argv)\n \tchar **heads = NULL;\n \tint fd[2], ret;\n \tpid_t pid;\n+\tchar *remote_name = NULL;\n+\tstruct remote *remote = NULL;\n \n \tsetup_git_directory();\n \tgit_config(git_default_config);\n@@ -362,6 +387,10 @@ int main(int argc, char **argv)\n \t\t\t\treceivepack = arg + 7;\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!prefixcmp(arg, \"--remote=\")) {\n+\t\t\t\tremote_name = arg + 9;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strcmp(arg, \"--all\")) {\n \t\t\t\tsend_all = 1;\n \t\t\t\tcontinue;\n@@ -394,10 +423,18 @@ int main(int argc, char **argv)\n \t\tusage(send_pack_usage);\n \tverify_remote_names(nr_heads, heads);\n \n+\tif (remote_name) {\n+\t\tremote = remote_get(remote_name);\n+\t\tif (!remote_has_uri(remote, dest)) {\n+\t\t\tdie(\"Destination %s is not a uri for %s\",\n+\t\t\t dest, remote_name);\n+\t\t}\n+\t}\n+\n \tpid = git_connect(fd, dest, receivepack);\n \tif (pid < 0)\n \t\treturn 1;\n-\tret = send_pack(fd[0], fd[1], nr_heads, heads);\n+\tret = send_pack(fd[0], fd[1], remote, nr_heads, heads);\n \tclose(fd[0]);\n \tclose(fd[1]);\n \tret |= finish_connect(pid);\n-- \n1.5.2.rc2.90.gc593-dirty\n"},{"id":"42312","messageId":"20070516120237.GA11852@coredump.intra.peff.net","threadId":"8173","inReplyTo":"7vtzudhayr.fsf@assigned-by-dhcp.cox.net","subject":"Re: pull/push inconsistencies","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-16T12:02:37Z","receivedAt":"2007-05-16T12:02:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 15, 2007 at 05:24:28PM -0700, Junio C Hamano wrote:\n\n> > My second issue is that git-push does not update\n> > remotes// so if I do git-push && gitk --all it looks\n> > as if I haven't pushed. Misleading again. :-/\n> \n> The standard answer is not to push into a live repository\n> without understanding what you are doing.\n\nMy impression here is that Martin is saying that pushing does not update\nthe remote tracking branch in the local repository (as, e.g., cogito has\nalways done). But I thought somebody (Ted?) recently submitted a patch\nto change that.\n\n> git-push without parameters and configuration pushes matching\n> branches. This has been true from day one. Again, I think we\n> should be able to make this safer so that \"git-push\" in cloned\n> repository would do something more restricted (perhaps limiting\n> to refs/heads?), but I do not think of a universally acceptable\n> canned configuration.\n\nI had done a patch in that direction (actually, it just avoided pushing\nrefs/remotes/) and have been planning to follow up with restricting\ngit-push to just refs/heads/. I'll try to work on that in the next day\nor so.\n\n-Peff\n"},{"id":"42339","messageId":"46a038f90705161535t6f15bbedy661accb54a9bd8c5@mail.gmail.com","threadId":"8173","inReplyTo":"46a038f90705151851i9027e01x993300b1b50d0285@mail.gmail.com","subject":"Re: pull/push inconsistencies","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-05-16T22:35:27Z","receivedAt":"2007-05-16T22:35:27Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/16/07, Martin Langhoff wrote:\n> I'm probably in a bad-communication day :-/\n\nOk - I just repro'd the problem -- maybe this helps clarify...\n\nI have a checkout of http://git.catalyst.net.nz/git/moodle-r2.git (\nsee http://git.catalyst.net.nz/gitweb ) where I have the following\ntracking branches:\n\n $ git branch\n mdl17-polhn\n * mdl18-local\n\nI know that I am \"all pushed out\" - no local commits to push here. So\nI start my day and do\n\n $ git-pull\n # brings some commits, but nothing to mdl18-local\n $ git-merge origin/MOODLE_18_STABLE\n # messy merge from the upstream branch I track...\n $ git-commit\n $ git-push\n $ git-push\n updating 'refs/heads/mdl18-local'\n from f3f1ae5c9f73fe6e0872dfe0e072521b6fe26463\n to 3af93dafbd9162423e5f0a720d4d2081313789e2\n updating 'refs/remotes/origin/MOODLE_18_STABLE'\n from 52abd5d7c4f0ac54cfc0463d5276c159a02a76c0\n to 4cfaa3c85ee54ec8c0891157a6becdd8db34eb52\n updating 'refs/remotes/origin/cvshead'\n from 7bf579b243717c470770b1457a7d1c50f6a8dff6\n to e835361626c5cd27cabdc046fc0e23a2c6ff98db\n updating 'refs/remotes/origin/mdl18-ldc'\n from eb91f220ccbbeb1e8b43496d0172e6cd1b6549ea\n to af4c6ee952057d11b2dbf55103a5c3134640b70f\n updating 'refs/remotes/origin/mdl18-topnz'\n from a08fdb4decfa7b92c3030801c08378ee629c038d\n to 347bc44adbfdf7b800334cbb532d436fa73e87ac\n (removed some tag-related noise)\n Generating pack...\n Done counting 212 objects.\n Result has 72 objects.\n Deltifying 72 objects...\n 100% (72/72) done\n Writing 72 objects...\n Unpacking 72 objects\n 100% (72/72) done\n Total 72 (delta 65), reused 0 (delta 0)\n refs/heads/mdl18-local: f3f1ae5c9f73fe6e0872dfe0e072521b6fe26463 ->\n 3af93dafbd9162423e5f0a720d4d2081313789e2\n refs/remotes/origin/MOODLE_18_STABLE:\n52abd5d7c4f0ac54cfc0463d5276c159a02a76c0 ->\n4cfaa3c85ee54ec8c0891157a6becdd8db34eb52\n refs/remotes/origin/cvshead:\n7bf579b243717c470770b1457a7d1c50f6a8dff6 ->\ne835361626c5cd27cabdc046fc0e23a2c6ff98db\n refs/remotes/origin/mdl18-ldc:\neb91f220ccbbeb1e8b43496d0172e6cd1b6549ea ->\naf4c6ee952057d11b2dbf55103a5c3134640b70f\n refs/remotes/origin/mdl18-topnz:\na08fdb4decfa7b92c3030801c08378ee629c038d ->\n347bc44adbfdf7b800334cbb532d436fa73e87ac\n\nAs you can see, it talks about updating lots of refs. Nonsense -- I\nthink it's a bug. The only ref being updated is origin/mdl18-local on\nthe remote repo, and it should update the local\nrefs/remotes/origin/mdl18-local.\n\ncheers,\n\n\nm\n"}]}