{"thread":{"id":"3113","subject":"\"git push\" logic changed?","startedAt":"2006-01-20T22:53:36Z","lastAt":"2006-01-24T05:05:09Z","messageCount":13,"participants":["Greg KH","Junio C Hamano","Daniel Barkalow","sean"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14965","messageId":"20060120225336.GA29206@kroah.com","threadId":"3113","inReplyTo":null,"subject":"\"git push\" logic changed?","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2006-01-20T22:53:36Z","receivedAt":"2006-01-20T22:53:36Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"As of the git development tree from last night, 'git push' seems to work\na bit differently now.\n\nWhen I do:\n\t$ git push parent\nit responds with\n\tNo refs given to be pushed.\n\nThis used to work before.\nNow I have to do:\n\t$ git push --all parent\nto get things to be pushed.\n\nOr should I always be doing --all?\n\nthanks,\n\ngreg k-h\n"},{"id":"14966","messageId":"7vlkxa30rd.fsf@assigned-by-dhcp.cox.net","threadId":"3113","inReplyTo":"20060120225336.GA29206@kroah.com","subject":"Re: \"git push\" logic changed?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-21T00:03:50Z","receivedAt":"2006-01-21T00:03:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg KH writes:\n\n> As of the git development tree from last night, 'git push' seems to work\n> a bit differently now.\n\nThe change was 9e9b267. I suspect the earlier way was a bit\nmore friendly to savvier people (especially the subsystem\nmaintainers and the project lead), but it was found to be\nconfusing for people who clone from an upstream and then use\nthat as a shared repository. Their developers further clone\nfrom that shared repository, and as needed pull from the true\nupstream. When they push their changes back, \"git push\ncentral:/shared.git/\" would trigger a \"remote origin does not\nfast forward\" error, depending on when these developers fetched\nfrom the shared repository the last time, and whether they\nstored what they fetched from the shared repository in their\n\"origin\" or not. If you do \"git pull central:/shared.git/\", not\n\"git pull origin\" (taking advantage of remotes/origin file),\nyour \"origin\" branch would become out-of-date. Which is OK for\nthe purpose of maintaining \"master\" branch properly, but pushing\nmeaningless \"origin\" back to \"origin\" at the shared repository\n(which is also meaningless) was triggering an error and causing\nconfusion in that setup.\n\n> Or should I always be doing --all?\n\nIn order to make sure all your local refs are on the \"parent\",\nthen yes. And this is not new. It used to push all the refs\nthat appear in _both_ your local repo and the \"parent\" repo, so\nyour new tags and branches did not get propagated so you needed\nto use '--all' in such a case anyway. We now also have '--tags'\nto push all tags.\n\nWe could probably resurrect the earlier behaviour with a\n'--matching' option or something if you'd like.\n"},{"id":"14967","messageId":"20060121001547.GA30712@kroah.com","threadId":"3113","inReplyTo":"7vlkxa30rd.fsf@assigned-by-dhcp.cox.net","subject":"Re: \"git push\" logic changed?","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2006-01-21T00:15:47Z","receivedAt":"2006-01-21T00:15:47Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Fri, Jan 20, 2006 at 04:03:50PM -0800, Junio C Hamano wrote:\n> Greg KH writes:\n> \n> > As of the git development tree from last night, 'git push' seems to work\n> > a bit differently now.\n> \n> The change was 9e9b267. I suspect the earlier way was a bit\n> more friendly to savvier people (especially the subsystem\n> maintainers and the project lead), but it was found to be\n> confusing for people who clone from an upstream and then use\n> that as a shared repository. Their developers further clone\n> from that shared repository, and as needed pull from the true\n> upstream. When they push their changes back, \"git push\n> central:/shared.git/\" would trigger a \"remote origin does not\n> fast forward\" error, depending on when these developers fetched\n> from the shared repository the last time, and whether they\n> stored what they fetched from the shared repository in their\n> \"origin\" or not. If you do \"git pull central:/shared.git/\", not\n> \"git pull origin\" (taking advantage of remotes/origin file),\n> your \"origin\" branch would become out-of-date. Which is OK for\n> the purpose of maintaining \"master\" branch properly, but pushing\n> meaningless \"origin\" back to \"origin\" at the shared repository\n> (which is also meaningless) was triggering an error and causing\n> confusion in that setup.\n\nWell what should I do then to push to \"orgin\"?\n\t$ git push\n\tWhere would you want to push today?\n\tUsage: /home/greg/bin/git-push [--all] [--tags] [--force] [...]\n\n\t$ git push origin\n\tNo refs given to be pushed.\n\n> > Or should I always be doing --all?\n> \n> In order to make sure all your local refs are on the \"parent\",\n> then yes. And this is not new. It used to push all the refs\n> that appear in _both_ your local repo and the \"parent\" repo, so\n> your new tags and branches did not get propagated so you needed\n> to use '--all' in such a case anyway. We now also have '--tags'\n> to push all tags.\n\nYes, but \"git push origin\" used to push my local changes there, and\nthat's all I really want.\n\nSomeone off-list told me I could edit my .git/branches/parent file to\nfix this issue for that branch. Since I hand-created that file in the\nfirst place, that's not a bit deal. But I was relying on git to get the\n\"origin\" branch right, as I didn't edit it at all :)\n\nSo, what I'm really just looking for is a simple way to push back to the\nrepository that I cloned this one from, as I only have one \"repo\" here.\n\n> We could probably resurrect the earlier behaviour with a\n> '--matching' option or something if you'd like.\n\nIt would be nicer not to break a previously working command :)\n\nOr at least show me how to change it so I can just easily push back to\nwhere I cloned the original from...\n\nthanks,\n\ngreg k-h\n"},{"id":"14968","messageId":"7vacdq2yez.fsf@assigned-by-dhcp.cox.net","threadId":"3113","inReplyTo":"20060121001547.GA30712@kroah.com","subject":"Re: \"git push\" logic changed?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-21T00:54:28Z","receivedAt":"2006-01-21T00:54:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg KH writes:\n\n> Well what should I do then to push to \"orgin\"?\n>...\n> Yes, but \"git push origin\" used to push my local changes there, and\n> that's all I really want.\n>\n> Someone off-list told me I could edit my .git/branches/parent file to\n> fix this issue for that branch. Since I hand-created that file in the\n> first place, that's not a bit deal. But I was relying on git to get the\n> \"origin\" branch right, as I didn't edit it at all :)\n\nIf you cloned from \"origin\", then you would have gotton\nsomething like:\n\n\tURL: that.machine:/this/directory.git\n Pull: master:origin\n\nin your \".git/remotes/origin\". Since there are more downloaders\nand individual developers than subsystem maintainers, this is a\ngood default for the former class of people.\n\nYou as the tree owner would then add \"Push:\" line(s) to push\nback from your local repository. For example:\n\n\t$ cat .git/remotes/origin\t\n\tURL: that.machine:/this/directory.git\n Pull: master:origin\n\tPush: master:master\n\nWith this,\n\n\t$ git push origin\n\nwould push master branch to that.machine:/this/directory.git/\nrepository. With --tags or --all:\n\n\t$ git push --tags origin\n $ git push --all origin\n\nThese \"Push:\" lines are for people who have write access to the\nother side (which is a minority compared to downloaders), so git\ndoes not create them by default when you clone the repository.\n"},{"id":"14969","messageId":"7v1wz22y6w.fsf@assigned-by-dhcp.cox.net","threadId":"3113","inReplyTo":"20060121001547.GA30712@kroah.com","subject":"Re: \"git push\" logic changed?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-21T00:59:19Z","receivedAt":"2006-01-21T00:59:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg KH writes:\n\n> It would be nicer not to break a previously working command :)\n\nWell the change was not about breaking things but the command's\nnatural way of \"working\" (which was fine for you and other\npeople, me included) was not so helpful to the shared repository\npeople, and unfortunately I couldn't have it both ways X-<.\n"},{"id":"14971","messageId":"7vfynivx9s.fsf_-_@assigned-by-dhcp.cox.net","threadId":"3113","inReplyTo":"20060121001547.GA30712@kroah.com","subject":"[RFC] Reverting \"git push logic change\"?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-21T07:46:23Z","receivedAt":"2006-01-21T07:46:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The change introduced by 9e9b267 commit broke \"correct\" usage of\ngit push to push matching refs, to work around a problem\nobserved in a usage pattern on a shared repository.\n\nI think I made a bad judgement in evaluating the scenario, and\nmade a bad change to \"fix\" a problem that did not exist. I\napologize for having caused this confusion.\n\nMy conclusion after thinking about the problem again is that we\nwould be better of if we reverted that commit. This message is\nto make my intention clear, and solicit objections or comments\nfrom the list.\n\nThe use case that prompted this change was this:\n\n - A shared repository is created by cloning Linus repository.\n This repository gets \"origin\" (then-current Linus master) and\n \"master\" (the same).\n\n\t$ git clone --naked \\\n git://git.kernel.org/.../linux-2.6.git/ project.git\n\n - Two developers use this as their shared repository. They\n first start out by cloning from it, do their development in\n their \"master\" branch and pushing back to the \"master\" branch\n of the shared repository. Their workflow is:\n\n\t0. Clone it (once per developer):\n $ git clone ssh://pub.example.com/project.git/ work\n\n\t1. To make sure the developers are in sync:\n\t$ git pull ssh://pub.example.com/project.git/ ;# (a) or\n\t$ git pull origin\t\t\t ;# (b)\n\n 2. His own development:\n\t$ edit;compile;test;git commit\n\n\t3. Pull from upstream, to avoid conflicts with it (only when needed):\n\t$ git pull git://git.kernel.org/.../linux-2.6.git/\n\n\t4. Push back the result to shared repository:\n $ git push ssh://pub.example.com/project.git/\n\nWith this workflow, in the two developer repositories, \"origin\"\nbranch is not really well maintained. If \"git pull origin\" was\nused with the remotes/origin file \"git clone\" initially gave\nhim, it would have kept track of the latest push into the shared\n\"master\" closely, but if the explicit URL was used, \"origin\" of\nthe developer repository would have been left behind.\n\nThis is not problem as far as the correctness of the \"master\"\nbranch is concerned. The fast-forward check when pushing into\nthe shared repository \"master\" branch prevents the two\ndevelopers from losing commits. In other words, either way to\npull from the shared repository is legal/valid.\n\nHowever, the push done in step 4. triggers the default \"push all\nmatching refs\" behaviour. All three repositories have \"origin\"\nand \"master\", which means this results in \"origin\" being updated\nin the shared repository. But one developer repository has a\nstale \"origin\" while the other developer has an up-to-date\n\"origin\". This triggers a \"not a fast forward\" error, which\ndoes not cause the push of \"master\" to fail, but still looks\nworrisome.\n\nI think the correct thing to do in this workflow is to simply\nremove \"origin\" branch from the shared repository. \n\nUsing or not using \"origin\" as a reference branch to keep track\nof what was fetched from the shared repository is a matter of\npersonal taste for each developer, and there is no reason to\nenforce either (1-a) or (1-b). This means that the branch is\nnot maintained the same way in developer repositories, and there\nis no point pushing into it --- there is no point to have\n\"origin\" in the shared repository.\n\nOnce \"origin\" branch is removed from that shared repository,\nthen, either \"push all matching refs\", or \"push 'master'\nexplicitly\" would work well for these developers.\n"},{"id":"15042","messageId":"Pine.LNX.4.64.0601221311530.25300@iabervon.org","threadId":"3113","inReplyTo":"7vfynivx9s.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Reverting \"git push logic change\"?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-01-22T19:09:50Z","receivedAt":"2006-01-22T19:09:50Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 20 Jan 2006, Junio C Hamano wrote:\n\n> The change introduced by 9e9b267 commit broke \"correct\" usage of\n> git push to push matching refs, to work around a problem\n> observed in a usage pattern on a shared repository.\n> \n> I think I made a bad judgement in evaluating the scenario, and\n> made a bad change to \"fix\" a problem that did not exist. I\n> apologize for having caused this confusion.\n> \n> My conclusion after thinking about the problem again is that we\n> would be better of if we reverted that commit. This message is\n> to make my intention clear, and solicit objections or comments\n> from the list.\n> \n> The use case that prompted this change was this:\n> \n> - A shared repository is created by cloning Linus repository.\n> This repository gets \"origin\" (then-current Linus master) and\n> \"master\" (the same).\n> \n> \t$ git clone --naked \\\n> git://git.kernel.org/.../linux-2.6.git/ project.git\n> \n> - Two developers use this as their shared repository. They\n> first start out by cloning from it, do their development in\n> their \"master\" branch and pushing back to the \"master\" branch\n> of the shared repository. Their workflow is:\n> \n> \t0. Clone it (once per developer):\n> $ git clone ssh://pub.example.com/project.git/ work\n> \n> \t1. To make sure the developers are in sync:\n> \t$ git pull ssh://pub.example.com/project.git/ ;# (a) or\n> \t$ git pull origin\t\t\t ;# (b)\n> \n> 2. His own development:\n> \t$ edit;compile;test;git commit\n> \n> \t3. Pull from upstream, to avoid conflicts with it (only when needed):\n> \t$ git pull git://git.kernel.org/.../linux-2.6.git/\n> \n> \t4. Push back the result to shared repository:\n> $ git push ssh://pub.example.com/project.git/\n> \n> With this workflow, in the two developer repositories, \"origin\"\n> branch is not really well maintained. If \"git pull origin\" was\n> used with the remotes/origin file \"git clone\" initially gave\n> him, it would have kept track of the latest push into the shared\n> \"master\" closely, but if the explicit URL was used, \"origin\" of\n> the developer repository would have been left behind.\n> \n> This is not problem as far as the correctness of the \"master\"\n> branch is concerned. The fast-forward check when pushing into\n> the shared repository \"master\" branch prevents the two\n> developers from losing commits. In other words, either way to\n> pull from the shared repository is legal/valid.\n> \n> However, the push done in step 4. triggers the default \"push all\n> matching refs\" behaviour. All three repositories have \"origin\"\n> and \"master\", which means this results in \"origin\" being updated\n> in the shared repository. But one developer repository has a\n> stale \"origin\" while the other developer has an up-to-date\n> \"origin\". This triggers a \"not a fast forward\" error, which\n> does not cause the push of \"master\" to fail, but still looks\n> worrisome.\n\nI think there are a number of good solutions:\n\n - Make the case of a pure rewind (i.e., pushing something that would be a \n fast-forward in the other direction) have no effect and give a more \n positive message like 'Remote \"origin\" is already ahead of your \n version.' I expect that something of that sort would comfort the users \n and distinguish branches that you're not actively using and have fallen \n behind on from branches that you are using, but someone else is also \n using. This seems like a good idea even if we do other stuff.\n - Have a command to write, report, and modify remotes files, so Greg can \n tell it exactly what he actually wants without mucking around with the \n files by hand. Also generally nice.\n - Require --all in push, but, if none are given, produce a summary of \n what you could specify instead of assuming you mean to push nothing. \n Then Greg would see master:master as the obvious thing, and do that.\n - Maybe \"git clone\" should add \"Push: master:master\" by default if the \n URL permits pushing?\n\nI think that having it default to matching branches isn't really ideal, \nsince that seems to me to work for practically everybody only by \ncoincidence: master:master is by far the most common case; then \nthere are some people who use multiple branches, but they must have done \nsomething other than the default to create this situation, anyway; then \nthere's the case where \"master\" isn't a head on both sides, but (at least \nin my experience), master:master is still what the user means (case \nhappens when pushing a first commit from a clone of an empty repository). \n\nMaybe the default should be master:master? It seems to fit the general \npattern of defaulting to master. Or maybe (what HEAD points to):(matching \nbranch), or (but I'm not too comfortable with this one) HEAD:master.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"15045","messageId":"7vr770c8db.fsf@assigned-by-dhcp.cox.net","threadId":"3113","inReplyTo":"Pine.LNX.4.64.0601221311530.25300@iabervon.org","subject":"Re: [RFC] Reverting \"git push logic change\"?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-22T20:31:28Z","receivedAt":"2006-01-22T20:31:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> - Make the case of a pure rewind (i.e., pushing something that would be a \n> fast-forward in the other direction) have no effect and give a more \n> positive message like 'Remote \"origin\" is already ahead of your \n> version.'\n\nIf the remote is not behind you, you would not be able to tell\nif it is ahead of you or totally unrelated, unless you fetch\nfrom them. So I am afraid this is unpractical.\n\n> - Have a command to write, report, and modify remotes files, so Greg can \n> tell it exactly what he actually wants without mucking around with the \n> files by hand. Also generally nice.\n\nFor the record, it was somebody else. Greg has the repositories\non both ends set up correctly, and does not suffer from this\n\"left behind origin\" error message. He has every right to\nexpect the \"all the matching refs\" semantics to keep working.\n\nI think in this case, it was not the lack of tool to \"tell it\nexactly what he actually wants\", but \"what he actually wants\"\nwas not quite well understood by the developers who experienced\nthis problem (again, not Greg). This is a user error but that\nis not their fault. It means that we need to document this\nbetter:\n\n\tA typical \"cloned\" repository has an \"origin\" branch to\n\trecord the head commit of the upstream repository when\n\tthe repository was cloned, and the branch is used to\n\tkeep track of further development at the upstream. But\n\tin a shared repository, it usually is not used for\n\tfurther development by your developers who clone from it\n\tand then push their changes back to it (for that they\n\twould use the \"master\" branch). Your developers may\n\toccasionally need to sync with the upstream, but that is\n\tdone by pulling from the upstream directly, and the\n\t\"origin\" branch at the shared repository is not\n\tinvolved. In other words, that branch is useless and\n\ttends to be left behind. If you are preparing a\n\trepository by first cloning from somewhere else, remove\n\tbranches that your developers and people who download\n\tfrom your shared repository do not use, including\n\t\"origin\".\n\n\t\"git push\", without telling the tool which branches to\n push explicitly, pushes the branches that exist on both\n ends. Culling unused branches, especially \"origin\",\n from the shared repository helps your developers because\n they do not have to do anything special to prevent their\n \"origin\" from being pushed back to the shared repository.\n\nor something like that.\n\n> - Require --all in push, but, if none are given, produce a summary of \n> what you could specify instead...\n\nThis is essentially what the \"fix\" did, except giving a summary.\nThe effect to the end user was that we were robbing \"matching\nrefs\" option from them.\n\n> - Maybe \"git clone\" should add \"Push: master:master\" by default if the \n> URL permits pushing?\n\nThis might be a good thing to have. I suspect majority of users\nwould benefit from this.\n\n> I think that having it default to matching branches isn't really ideal, \n> since that seems to me to work for practically everybody only by \n> coincidence: master:master is by far the most common case; then \n> there are some people who use multiple branches, but they must have done \n> something other than the default to create this situation, anyway;\n\nActually I started to think matching is a very good default for\neveryday use.\n\n - In the recommended \"topic branches\" workflow, a developer\n repository has more branches than his public repository he\n pushes into. A typical public repository on kernel.org has\n either \"master\" alone, or \"test\" and \"release\" pair. In\n either case, I expect the set of branches on these public\n repositories have \"matching\" ones in the owners' development\n repositories. \"matching\" push lets them updated without\n pushing topic branch heads _unless_ the developer also wants\n to push topic branches to public, which reduces the clutter\n on the public repository.\n\n - In a shared repository setup, a developer still can employ\n topic branches workflow for himself. The same \"matching\n semantics prevents unneeded exposure of private topic\n branches\" applies here.\n\n - In a non-default developer repository that has more than one,\n they must have done something other than the default. For\n example:\n\n\t$ git branch test\n $ git branch release\n $ git push public:myrepo test release\n\n We _could_ require (or strongly suggest) them to keep a\n remotes/ shorthand for push destination and have:\n\n\tURL: public:myrepo\n Push: test\n Push: release\n\n so that next push would be \"git push public\". Another\n possibility is that \"git push public test release\"\n (i.e. using a \"remotes/public\" shorthand) _could_ offer to\n update the remotes/ file when it sees these branches do not\n appear on Push: lines.\n\n But the \"matching ones\" push has the same effect. It\n remembers which ones have been pushed out before, without\n mucking with remotes/ file, as long as the branch names are\n the same on the both ends (which I suspect is the most common\n usage).\n\n Also we need to remember there are people who push into more\n than one repositories, and they would need to keep and\n maintain separate remotes/ file per destination if there is\n no \"matching ones\" option.\n\nIf we add \"Push: master\" upon clone from host:repo (or local),\nthen these new repositories would push master into master and\nnothing else with \"git push origin\", and \"git push URL\" to the\nsame remote repository without using remotes/ shorthand would\nresult in the matching behaviour. That may be a good default.\n"},{"id":"15050","messageId":"7vu0bw9ch7.fsf@assigned-by-dhcp.cox.net","threadId":"3113","inReplyTo":"7vr770c8db.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Reverting \"git push logic change\"?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-22T21:31:00Z","receivedAt":"2006-01-22T21:31:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> ... This is a user error but that is not their fault. It\n> means that we need to document this better:\n\nI hope something like this is clear enough?\n\n-- >8 --\n[PATCH] Recommend to remove unused `origin` in a shared repository\n\nIt is a common mistake to leave an unsed `origin` branch behind\nif a shared public repository was created by first cloning from\nsomewhere else. Subsequent `git push` into it with the default\n\"push all the matching ref\" would push the `origin` branch from\nthe developer repository uselessly.\n\nSigned-off-by: Junio C Hamano \n---\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\nindex b8fa299..35579cc 100644\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -1667,6 +1667,26 @@ complain, telling you that the remote `m\n fast forward. You need to pull and merge those other changes\n back before you push your work when it happens.\n \n+The `git push` command without any explicit refspec parameter\n+pushes the refs that exist both in the local repository and the\n+remote repository. So the last `push` can be done with either\n+one of these:\n+------------\n+$ git push origin\n+$ git push repo.shared.xz:/pub/scm/project.git/\n+------------\n+as long as the shared repository does not have any branches\n+other than `master`.\n+[NOTE]\n+============\n+If you created your shared repository by cloning from somewhere\n+else, you may have the `origin` branch. Your developers\n+typically do not use that branch; remove it. Otherwise, that\n+would be pushed back by the `git push origin` because your\n+developers' repository would surely have `origin` branch to keep\n+track of the shared repository, and would be counted as \"exist\n+on both ends\".\n+============\n \n Advanced Shared Repository Management\n -------------------------------------\n"},{"id":"15051","messageId":"BAYC1-PASMTP0532B701820FA4ADB3C640AE110@CEZ.ICE","threadId":"3113","inReplyTo":"7vu0bw9ch7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Reverting \"git push logic change\"?","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-01-22T21:42:50Z","receivedAt":"2006-01-22T21:42:50Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 22 Jan 2006 13:31:00 -0800\nJunio C Hamano wrote:\n\n\n> +If you created your shared repository by cloning from somewhere\n> +else, you may have the `origin` branch. Your developers\n> +typically do not use that branch; remove it. Otherwise, that\n> +would be pushed back by the `git push origin` because your\n> +developers' repository would surely have `origin` branch to keep\n> +track of the shared repository, and would be counted as \"exist\n> +on both ends\".\n\n\nWhat about just always excluding the origin branch from being \nimplicitly pushed; even if it does exist in both repositories?\nIn the rare cases where it is actually desired to be pushed,\nit can be done explicitly.\n\nSean\n"},{"id":"15052","messageId":"7vpsmjamgw.fsf@assigned-by-dhcp.cox.net","threadId":"3113","inReplyTo":"BAYC1-PASMTP0532B701820FA4ADB3C640AE110@CEZ.ICE","subject":"Re: [RFC] Reverting \"git push logic change\"?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-22T23:09:51Z","receivedAt":"2006-01-22T23:09:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"sean writes:\n\n> What about just always excluding the origin branch from being \n> implicitly pushed; even if it does exist in both repositories?\n> In the rare cases where it is actually desired to be pushed,\n> it can be done explicitly.\n\nThe problem is \"origin\" is just a Porcelain convention and we\nwould not want to teach that to the core level, so that will not\nfly.\n"},{"id":"15056","messageId":"7vacdnafx1.fsf@assigned-by-dhcp.cox.net","threadId":"3113","inReplyTo":"7vpsmjamgw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Reverting \"git push logic change\"?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-23T01:31:22Z","receivedAt":"2006-01-23T01:31:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> sean writes:\n>\n>> What about just always excluding the origin branch from being \n>> implicitly pushed; even if it does exist in both repositories?\n>> In the rare cases where it is actually desired to be pushed,\n>> it can be done explicitly.\n>\n> The problem is \"origin\" is just a Porcelain convention and we\n> would not want to teach that to the core level, so that will not\n> fly.\n\nOne improvement that can be done is to update \"git clone --bare\"\nso that it does not create \"origin\", which is more or less\npointless for such a \"distribution point\" repository.\n\nThis reminds me that I need to deprecate --naked and introduce --bare\nto the clone command...\n"},{"id":"15079","messageId":"20060124050509.GD22848@kroah.com","threadId":"3113","inReplyTo":"7vfynivx9s.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Reverting \"git push logic change\"?","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2006-01-24T05:05:09Z","receivedAt":"2006-01-24T05:05:09Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Fri, Jan 20, 2006 at 11:46:23PM -0800, Junio C Hamano wrote:\n> The change introduced by 9e9b267 commit broke \"correct\" usage of\n> git push to push matching refs, to work around a problem\n> observed in a usage pattern on a shared repository.\n\n\n\nThanks, I think this makes a bit more sense.\n\nIf nothing else, the documentation should be updated to reflect the\nchange in 9e9b267 :)\n\nthanks,\n\ngreg k-h\n"}]}