{"thread":{"id":"8564","subject":"Problem with a push","startedAt":"2007-06-11T21:32:47Z","lastAt":"2007-07-02T02:00:08Z","messageCount":15,"participants":["Alex R.M. Turner","Linus Torvalds","Junio C Hamano","Andy Parkins","Jon Loeliger","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"44761","messageId":"Pine.LNX.4.64.0706111632050.4406@www.mintpixels.com","threadId":"8564","inReplyTo":null,"subject":"Problem with a push","fromName":"Alex R.M. Turner","fromEmail":"aturner@plexq.com","sentAt":"2007-06-11T21:32:47Z","receivedAt":"2007-06-11T21:32:47Z","isPatch":false,"sender":{"key":"aturner@plexq.com","avatar":null},"body":"\nI get the following error when pushing after a merge:\n\nupdating 'refs/heads/master'\n from c18f9e4350c26e6b45d0a282ff32991784becbdd\n to 39b7d927720c9f2810e0af5311975119c0d7c7bd\nupdating 'refs/remotes/origin/HEAD'\n from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0\n to c18f9e4350c26e6b45d0a282ff32991784becbdd\nupdating 'refs/remotes/origin/master'\n from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0\n to c18f9e4350c26e6b45d0a282ff32991784becbdd\nGenerating pack...\nDone counting 26 objects.\nResult has 10 objects.\nDeltifying 10 objects...\n 100% (10/10) done\nWriting 10 objects...\n 100% (10/10) done\nTotal 10 (delta 7), reused 0 (delta 0)\nrefs/heads/master: c18f9e4350c26e6b45d0a282ff32991784becbdd -> \n39b7d927720c9f2810e0af5311975119c0d7c7bd\nng refs/remotes/origin/master failed to lock\nrefs/remotes/origin/HEAD: 1e631edb3078ec3a4d1fa598c8f410f6a61659b0 -> \nc18f9e4350c26e6b45d0a282ff32991784becbdd\nerror: Ref refs/remotes/origin/master is at \nc18f9e4350c26e6b45d0a282ff32991784becbdd but expected \n1e631edb3078ec3a4d1fa598c8f410f6a61659b0\nerror: failed to lock refs/remotes/origin/master\nerror: failed to push to 'ssh://aturner@svn.mintpixels.com/data/git/mls'\n\nbut when I try it again, it just says Everything up-to-date.\n\nAlex\n"},{"id":"44769","messageId":"alpine.LFD.0.98.0706111556160.14121@woody.linux-foundation.org","threadId":"8564","inReplyTo":"Pine.LNX.4.64.0706111632050.4406@www.mintpixels.com","subject":"Re: Problem with a push","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-11T23:03:53Z","receivedAt":"2007-06-11T23:03:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jun 2007, Alex R.M. Turner wrote:\n> \n> I get the following error when pushing after a merge:\n> \n> updating 'refs/heads/master'\n> from c18f9e4350c26e6b45d0a282ff32991784becbdd\n> to 39b7d927720c9f2810e0af5311975119c0d7c7bd\n> updating 'refs/remotes/origin/HEAD'\n> from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0\n> to c18f9e4350c26e6b45d0a282ff32991784becbdd\n> updating 'refs/remotes/origin/master'\n> from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0\n> to c18f9e4350c26e6b45d0a282ff32991784becbdd\n\nOk, pushing out remote branches is a bit odd in the first place. As in \n\"you probably shouldn't do that\". The \"remote\" branches are really local \nto each repo, and updating them by pushing is really quite suspect.\n\nSo the regular \"master\" branch pushed out fine:\n\n> refs/heads/master: c18f9e4350c26e6b45d0a282ff32991784becbdd -> 39b7d927720c9f2810e0af5311975119c0d7c7bd\n\nand that part is all ok.\n\nHowever, I think the problem is this:\n\n> refs/remotes/origin/HEAD: 1e631edb3078ec3a4d1fa598c8f410f6a61659b0 -> c18f9e4350c26e6b45d0a282ff32991784becbdd\n\nYou updated the HEAD file, but that actually is a _symbolic_ ref, which \nnormally points to refs/removes/origin/HEAD, and that in turn explains the \nother errors:\n\n> ng refs/remotes/origin/master failed to lock\n> error: Ref refs/remotes/origin/master is at c18f9e4350c26e6b45d0a282ff32991784becbdd but expected 1e631edb3078ec3a4d1fa598c8f410f6a61659b0\n> error: failed to lock refs/remotes/origin/master\n> error: failed to push to 'ssh://aturner@svn.mintpixels.com/data/git/mls'\n\nWhat happened is that the \"remotes/origin/master\" branch already got \nupdated when you updated HEAD, so now git is complaining that you are \ntrying to update it again, but it no longer has the same value that it had \noriginally (since you changed it).\n\n> but when I try it again, it just says Everything up-to-date.\n\nRight. Because the HEAD update really already did all the changes (to \n_both_ remotes/origin/HEAD _and_ remotes/origin/master, since it was a \nsymref), so next time around there is nothing to push, and you won't see \nthis issue any more.\n\nSo I don't think there was anything reall bad going on, except for the \nfact that you really shouldn't try to push out remote branches.\n\nWhat was the command line? In particular, was this a \"git push --all\" or \nsomething? I think we should make sure that we do *not* push remotes by \ndefault (and if you really *really* want to push remotes, you'd have to \nspecify them explicitly).\n\n\t\t\tLinus\n"},{"id":"44773","messageId":"Pine.LNX.4.64.0706111832070.4830@www.mintpixels.com","threadId":"8564","inReplyTo":"alpine.LFD.0.98.0706111556160.14121@woody.linux-foundation.org","subject":"Re: Problem with a push","fromName":"Alex R.M. Turner","fromEmail":"aturner@plexq.com","sentAt":"2007-06-11T23:35:24Z","receivedAt":"2007-06-11T23:35:24Z","isPatch":false,"sender":{"key":"aturner@plexq.com","avatar":null},"body":"On Mon, 11 Jun 2007, Linus Torvalds wrote:\n\n> \n> \n> On Mon, 11 Jun 2007, Alex R.M. Turner wrote:\n> > \n> > I get the following error when pushing after a merge:\n> > \n> > updating 'refs/heads/master'\n> > from c18f9e4350c26e6b45d0a282ff32991784becbdd\n> > to 39b7d927720c9f2810e0af5311975119c0d7c7bd\n> > updating 'refs/remotes/origin/HEAD'\n> > from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0\n> > to c18f9e4350c26e6b45d0a282ff32991784becbdd\n> > updating 'refs/remotes/origin/master'\n> > from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0\n> > to c18f9e4350c26e6b45d0a282ff32991784becbdd\n> \n> Ok, pushing out remote branches is a bit odd in the first place. As in \n> \"you probably shouldn't do that\". The \"remote\" branches are really local \n> to each repo, and updating them by pushing is really quite suspect.\n> \n> So the regular \"master\" branch pushed out fine:\n> \n> > refs/heads/master: c18f9e4350c26e6b45d0a282ff32991784becbdd -> 39b7d927720c9f2810e0af5311975119c0d7c7bd\n> \n> and that part is all ok.\n> \n> However, I think the problem is this:\n> \n> > refs/remotes/origin/HEAD: 1e631edb3078ec3a4d1fa598c8f410f6a61659b0 -> c18f9e4350c26e6b45d0a282ff32991784becbdd\n> \n> You updated the HEAD file, but that actually is a _symbolic_ ref, which \n> normally points to refs/removes/origin/HEAD, and that in turn explains the \n> other errors:\n> \n> > ng refs/remotes/origin/master failed to lock\n> > error: Ref refs/remotes/origin/master is at c18f9e4350c26e6b45d0a282ff32991784becbdd but expected 1e631edb3078ec3a4d1fa598c8f410f6a61659b0\n> > error: failed to lock refs/remotes/origin/master\n> > error: failed to push to 'ssh://aturner@svn.mintpixels.com/data/git/mls'\n> \n> What happened is that the \"remotes/origin/master\" branch already got \n> updated when you updated HEAD, so now git is complaining that you are \n> trying to update it again, but it no longer has the same value that it had \n> originally (since you changed it).\n> \n> > but when I try it again, it just says Everything up-to-date.\n> \n> Right. Because the HEAD update really already did all the changes (to \n> _both_ remotes/origin/HEAD _and_ remotes/origin/master, since it was a \n> symref), so next time around there is nothing to push, and you won't see \n> this issue any more.\n> \n> So I don't think there was anything reall bad going on, except for the \n> fact that you really shouldn't try to push out remote branches.\n> \n> What was the command line? In particular, was this a \"git push --all\" or \n> something? I think we should make sure that we do *not* push remotes by \n> default (and if you really *really* want to push remotes, you'd have to \n> specify them explicitly).\n> \n> \t\t\tLinus\n> \nCool - that totally makes sense, HEAD is a link to master. so updating \nHEAD failed because it was already up to date. The command was simply:\n\ngit push\n\nThis repo was cloned from one on another server (the server I use to \nbackup everything) with a git clone command:\n\ngit clone ssh://aturner@svn.mintpixels.com/data/git/mls\n\n.git/config looks like this:\n[core]\n repositoryformatversion = 0\n filemode = true\n bare = false\n logallrefupdates = true\n[remote \"origin\"]\n url = ssh://aturner@svn.mintpixels.com/data/git/mls\n fetch = +refs/heads/*:refs/remotes/origin/*\n[branch \"master\"]\n remote = origin\n merge = refs/heads/master\n[user]\n email = alex@mintpixels.com\n name = Alex R.M. Turner\n\n\ngit branch -a shows:\n* master\n origin/HEAD\n origin/master\n\nBased on all this, what is the correct way to update my core repo on my \nserver? (I'm sorry - I'm pretty new to git, so I haven't quite cottoned on \nto some aspects yet).\n\nAlex\n"},{"id":"44775","messageId":"7vhcpenjao.fsf@assigned-by-dhcp.pobox.com","threadId":"8564","inReplyTo":"alpine.LFD.0.98.0706111556160.14121@woody.linux-foundation.org","subject":"Re: Problem with a push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-11T23:49:35Z","receivedAt":"2007-06-11T23:49:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> What was the command line? In particular, was this a \"git push --all\" or \n> something? I think we should make sure that we do *not* push remotes by \n> default (and if you really *really* want to push remotes, you'd have to \n> specify them explicitly).\n\nI suspect that people (probably rightfully) just say \"git push\"\nwithout saying anything else, and the so-useful-for-old-timers\ndefault \"matching refs\" behaviour bites them when they do so.\n\nIf you create a non-bare clone, clone from that, and then try to\npush from the second generation clone to the first generation\nnon-bare clone, surely there will be \"matching\" remotes/origin/,\nexcept that they are not really matching X-<.\n"},{"id":"44777","messageId":"alpine.LFD.0.98.0706111727240.14121@woody.linux-foundation.org","threadId":"8564","inReplyTo":"Pine.LNX.4.64.0706111832070.4830@www.mintpixels.com","subject":"Re: Problem with a push","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-12T00:40:20Z","receivedAt":"2007-06-12T00:40:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jun 2007, Alex R.M. Turner wrote:\n> \n> Cool - that totally makes sense, HEAD is a link to master. so updating \n> HEAD failed because it was already up to date.\n\nYes. Well, strictly speaking it failed because it _wasn't_ up-to-date \n*before* the push (so \"git push\" thought it should update it), but it had \nbecome up-to-date (through the symref link) by the time it was actually \nits turn to be updated.\n\n> The command was simply:\n> \n> git push\n\nOk, as Junio points out, it's then just the fact that both repositories \nhad the same \"remote\" refs, and then the default of just updating \neverything in common kicks in.\n\nThat default used to make sense back when, but it doesn't make sense for \nremotes, since those are generally \"local\" to each repo.\n\n> This repo was cloned from one on another server (the server I use to \n> backup everything) with a git clone command:\n\nYeah. Normally you'd (well, _I_ would) only push to bare repositories, and \nnormally you wouldn't make those bare repositories have \"remotes\" entries, \nwhich is why you're the first to apparently even notice this insanity.\n\nIt wasn't your fault, it's simply bad defaults for git behaviour.\n\nThe behaviour for \"git pull\" has improved _immensely_ over the last few \nmonths, but \"git push\" still does the same thing it always did, because \nfewer people care about pushing than pulling, and because the old \"git \npush\" behaviour of just updating all the branches in common actually \nhappens to be the right thing when you do *not* make the central \nrepository contain remote branches of its own.\n\n> Based on all this, what is the correct way to update my core repo on my \n> server? (I'm sorry - I'm pretty new to git, so I haven't quite cottoned on \n> to some aspects yet).\n\nWith the current git model, I would suggest:\n\n - for \"central\" repositories, use a bare repository, and don't create \n \"remotes\" branches in that central repository at all.\n\n - for other repositories, don't push into them, just _pull_ into them \n (because that also knows about updating the working tree etc: pushing \n is really meant to be done only into bare and central ones that don't \n actually have any work happening in them, and _cannot_ have any work \n happening in them because they don't even have a working directory \n associated with them)\n\nThat said, I don't think that's necessarily the right answer in the longer \nrun. It's how git people do things, but it's not necessarily the *best* \nway of doing things. I think the better solution in the longer term is to \nsimply improve how \"git push\" works:\n\n - we should probably do the same kinds of .git/config file entries for \n pushing as we do for fetching, and just get rid of the old implicit \n model, and instead have a nice refspec pattern model for what gets \n pushed instead.\n\n I _think_ the refspec cleanup work by Daniel makes this something we \n can almost already do. Daniel?\n\n - we should also likely have some way to specify what happens when you \n push into a branch that is currently checked out and has a working tree \n associated with it.\n\n This was briefly discussed a few weeks ago, but nobody cared enough, I \n suspect.\n\nanyway, I think the _proper_ thing to do would be to associate each \n[remote] entry in the config file with a \"push\" refspec pattern, the way \nwe do for \"fetch\" already.\n\n\t\tLinus\n"},{"id":"44782","messageId":"7vzm36lzua.fsf@assigned-by-dhcp.pobox.com","threadId":"8564","inReplyTo":"alpine.LFD.0.98.0706111727240.14121@woody.linux-foundation.org","subject":"Re: Problem with a push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-12T01:35:09Z","receivedAt":"2007-06-12T01:35:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> That said, I don't think that's necessarily the right answer in the longer \n> run. It's how git people do things, but it's not necessarily the *best* \n> way of doing things. I think the better solution in the longer term is to \n> simply improve how \"git push\" works:\n>\n> - we should probably do the same kinds of .git/config file entries for \n> pushing as we do for fetching, and just get rid of the old implicit \n> model, and instead have a nice refspec pattern model for what gets \n> pushed instead.\n>\n> I _think_ the refspec cleanup work by Daniel makes this something we \n> can almost already do. Daniel?\n\nThat has already been there long before Daniel's patches.\n\n> - we should also likely have some way to specify what happens when you \n> push into a branch that is currently checked out and has a working tree \n> associated with it.\n>\n> This was briefly discussed a few weeks ago, but nobody cared enough, I \n> suspect.\n\nThat actially is in the todo:TODO for some time. Just have been\ntoo busy to look into it.\n\n> anyway, I think the _proper_ thing to do would be to associate each \n> [remote] entry in the config file with a \"push\" refspec pattern, the way \n> we do for \"fetch\" already.\n\nI do not think that is enough. A sane thing if we were doing\n\"git push\" from scratch and there is no existing user's fingers\nto re-train, would be:\n\n * \"git-push\" without anything will default to \"git-push\n origin\"; this has been working for a long time.\n\n * \"git-push $remote\" when there is [remote] refspec config use\n that refspecs, not \"matching refs\"; this also has been\n working for a long time.\n\n * We would want to change git-push so that \"git-push $remote\"\n will _NOT_ default to 'matching refs'. We keep that\n 'matching refs' behaviour only when the other end is a bare\n repository.\n\n * For \"git-push $remote\" to a non-bare repository, that does\n not have [remote] push refspecs, we probably would want to\n change the default to refuse operation, or push only\n 'matching heads' (as opposed to 'matching refs').\n\nAlternatively, we could teach \"git clone\" and \"git remote add\"\nto add push refspec in the config, and keep the 'matching refs\nif there is no push refspec in the config' behaviour.\n\nHowever, the push refspec needs to be different depending on the\nbareness of the remote, and I do not see a good way to arrange\nthis.\n\n\"git clone\" does communicate with the remote, so theoretically\nwe ought to be able to do that, but there currently is no way to\nindicate bareness of the remote to the client.\n\n\"git remote add\" by default does not even communicate with the\nremote, so without telepathy that is even more cumbersome to\narrange than \"git clone\" case.\n"},{"id":"44811","messageId":"200706121007.17044.andyparkins@gmail.com","threadId":"8564","inReplyTo":"alpine.LFD.0.98.0706111556160.14121@woody.linux-foundation.org","subject":"Re: Problem with a push","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-06-12T09:07:15Z","receivedAt":"2007-06-12T09:07:15Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 June 12, Linus Torvalds wrote:\n\n> Ok, pushing out remote branches is a bit odd in the first place. As in\n> \"you probably shouldn't do that\". The \"remote\" branches are really local\n> to each repo, and updating them by pushing is really quite suspect.\n\nI agree its odd, but is it really true that one (I) shouldn't be doing it?\n\nCan I tell you what I'm doing, and check that it's not crazy...\n\nI have my laptop and my desktop computer; I use both for development. I've \nset them so that they are symmetric...\n\nlaptop:.git/config\n [remote \"desktop\"]\n url = ssh://blah blah blah\n fetch = refs/heads/*:refs/remotes/desktop/*\n push = refs/heads/*:refs/remotes/laptop/*\n\ndesktop:.git/config\n [remote \"laptop\"]\n url = ssh://blah blah blah\n fetch = refs/heads/*:refs/remotes/laptop/*\n push = refs/heads/*:refs/remotes/desktop/*\n\nThis is very handy, as git-push on one does the same as git-fetch on the \nother. Have I made a glaring mistake by pushing to a remote ref?\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"44839","messageId":"alpine.LFD.0.98.0706120800430.14121@woody.linux-foundation.org","threadId":"8564","inReplyTo":"200706121007.17044.andyparkins@gmail.com","subject":"Re: Problem with a push","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-12T15:07:59Z","receivedAt":"2007-06-12T15:07:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 12 Jun 2007, Andy Parkins wrote:\n> \n> I agree its odd, but is it really true that one (I) shouldn't be doing it?\n\nNo, it's definitely not a hard rule, and it's perfectly fine to push any \nrefs at all, including remotes.\n\nIt's just that we probably shouldn't do it by *default*.\n\nThere's another slight detail to this story, which is what caused Alex to \nnotice in the first place: we tried to push to something that was a \nsymref, which actually caused *another* ref to update. Again, there's \nnothing wrong about that theoretically (it's what symrefs are there for!), \nbut again, it's probably something we shouldn't do by default.\n\nSo there's a big difference between:\n\n - git _can_ do it, and it's perfectly sane to do when you know what you \n are doing and have a very specific issue.\n\nand\n\n - git not only _can_ do it, but will do it even when you didn't \n explicitly tell it to do that..\n\n> Can I tell you what I'm doing, and check that it's not crazy...\n> \n> I have my laptop and my desktop computer; I use both for development. \n> I've set them so that they are symmetric...\n> \n> laptop:.git/config\n> [remote \"desktop\"]\n> url = ssh://blah blah blah\n> fetch = refs/heads/*:refs/remotes/desktop/*\n> push = refs/heads/*:refs/remotes/laptop/*\n> \n> desktop:.git/config\n> [remote \"laptop\"]\n> url = ssh://blah blah blah\n> fetch = refs/heads/*:refs/remotes/laptop/*\n> push = refs/heads/*:refs/remotes/desktop/*\n> \n> This is very handy, as git-push on one does the same as git-fetch on the \n> other. Have I made a glaring mistake by pushing to a remote ref?\n\nI think this is perfectly sane, exactly because you did it explicitly, and \npartly exactly *because* you explicitly don't do what git push does by \ndefault (which is to update the \"remote\" refs remotely with what are the \nremote refs locally!).\n\nIOW, the notion of \"remote\" refs really logically implies a mirror image, \nexactly like you have it set up in your config: what is a local ref in one \nrepository is a remote ref in another. But that's not what the default \n\"git push\" semantics are: it just matches refs directly, without that \nmirroring.\n\nAnd the _reason_ for it doing that are obviously historical: we didn't use \nto have the notion of \"remotes\", so back when I did that, it made sense. \nIt just doesn't make sense any more.\n\nJunio: I suspect this is really an area worth changing semantics in, the \nsame way we changed the semantics for the defaults for \"git pull\". And I \nsuspect it will confuse a lot fewer people, because fewer people depend on \nthe default behaviour of \"git push\".\n\n\t\tLinus\n"},{"id":"44846","messageId":"7vk5u9hzv9.fsf@assigned-by-dhcp.pobox.com","threadId":"8564","inReplyTo":"alpine.LFD.0.98.0706120800430.14121@woody.linux-foundation.org","subject":"Re: Problem with a push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-12T17:00:26Z","receivedAt":"2007-06-12T17:00:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> IOW, the notion of \"remote\" refs really logically implies a mirror image, \n> exactly like you have it set up in your config: what is a local ref in one \n> repository is a remote ref in another. But that's not what the default \n> \"git push\" semantics are: it just matches refs directly, without that \n> mirroring.\n>\n> And the _reason_ for it doing that are obviously historical: we didn't use \n> to have the notion of \"remotes\", so back when I did that, it made sense. \n> It just doesn't make sense any more.\n\nThere are two aspects of this issue. If \"matching refs\"\nsemantics makes sense, and if pushing refs/remotes makes sense.\n\nI think the above description risks confusing new people by\nsounding as if you are saying no to the former question.\n\n\"Pushing to the ref of the same path\" makes _PERFECT_ sense even\ntoday for a push into a bare repository used for publishing.\n\nIt only is not the right thing to do 50% of the time when you\nare pushing into a live repository.\n\nAnd I everyday use an example of why \"matching refs\" makes sense\nfor the other 50% of \"push into a live repository\" case. When I\nwork on git.git, the second-from-final step every day is to push\ninto a live repository I have at k.org for final build in an\nenvironment different from what I use for development. I do\n\"matching refs\" push, go there and \"git reset --hard\" to update\nthe working tree to build all four branches (there is the issue\nthat I am too lazy to install receive-pack hook in the live\nrepository to do that reset --hard to sync the working tree for\nme, but that is a separate issue).\n\nSo it is not like \"matching refs\" is always wrong. It is wrong\nin some cases, and is perfectly good in some other cases.\n\nWhat does not make sense AT ALL is to push what you keep under\nrefs/remotes/ to outside. This issue actually has existed from\nthe very beginning, and we had a specific instruction that said\n\"remove 'refs/heads/origin' from your published repository\notherwise you will confuse yourself with push\". This was before\nseparate-remote layout was invented and refs/heads/origin was\nthe remote tracking branch for the 'master' at the other side.\n\nBack when you did the original \"send-pack\", there was nothing\noutside of refs/{heads,tags}, so historically it made sense to\nsay \"ALL matching\", but even then we had to be careful about\n'heads/origin'. Now it does not make sense anymore(I am saying\nthat not-renaming is OK but sending refs/remotes is Bad, which\nis quite different from what you said).\n\nProbably we should not do push anything other than refs/heads/\nwhen we do \"matching refs\"\n\nI think what we might want to do around this area are:\n\n - Don't change anything, if the command line says refspec, or\n the remote has push refspec specified.\n\n - When doing 'matching refs', do it only under refs/heads/.\n\n - Ship with a receive-pack hook that attempts a 3-way merge\n update when the currently checked out branch is updated.\n\nAdditionally we can give an option to \"git clone\" (or \"git\nremote add\") to arrange the cross-push configuration for\nmothership-satellite Andy showed in the clone's .git/config;\nbut I think that is a separate issue.\n"},{"id":"44855","messageId":"alpine.LFD.0.98.0706121055090.14121@woody.linux-foundation.org","threadId":"8564","inReplyTo":"7vk5u9hzv9.fsf@assigned-by-dhcp.pobox.com","subject":"Re: Problem with a push","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-12T18:01:52Z","receivedAt":"2007-06-12T18:01:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 12 Jun 2007, Junio C Hamano wrote:\n> \n> I think what we might want to do around this area are:\n> \n> - Don't change anything, if the command line says refspec, or\n> the remote has push refspec specified.\n> \n> - When doing 'matching refs', do it only under refs/heads/.\n\nI think these both are \"obviously good\".\n\n> - Ship with a receive-pack hook that attempts a 3-way merge\n> update when the currently checked out branch is updated.\n\nWell, if it wasn't a fast-forward, then the user did a push with \"git push \n-f\", which implies _replacing_ the currently checked out branch.\n\nSo by three-way, I assume you mean the \"git checkout -m\" behaviour, and a \nfast-forward. What about a non-fast-forward (ie \"git push -f\"?) Should \nthat imply \"git checkout -f\" semantics on the receiving side? That would \nkind of be sensible.\n\n\t\tLinus\n"},{"id":"44859","messageId":"Pine.LNX.4.64.0706121309260.7703@www.mintpixels.com","threadId":"8564","inReplyTo":"alpine.LFD.0.98.0706111727240.14121@woody.linux-foundation.org","subject":"Re: Problem with a push","fromName":"Alex R.M. Turner","fromEmail":"aturner@plexq.com","sentAt":"2007-06-12T18:14:15Z","receivedAt":"2007-06-12T18:14:15Z","isPatch":false,"sender":{"key":"aturner@plexq.com","avatar":null},"body":"On Mon, 11 Jun 2007, Linus Torvalds wrote:\n\n> \n> \n> On Mon, 11 Jun 2007, Alex R.M. Turner wrote:\n> > \n> > Cool - that totally makes sense, HEAD is a link to master. so updating \n> > HEAD failed because it was already up to date.\n> \n> Yes. Well, strictly speaking it failed because it _wasn't_ up-to-date \n> *before* the push (so \"git push\" thought it should update it), but it had \n> become up-to-date (through the symref link) by the time it was actually \n> its turn to be updated.\n> \n> > The command was simply:\n> > \n> > git push\n> \n> Ok, as Junio points out, it's then just the fact that both repositories \n> had the same \"remote\" refs, and then the default of just updating \n> everything in common kicks in.\n> \n> That default used to make sense back when, but it doesn't make sense for \n> remotes, since those are generally \"local\" to each repo.\n> \n> > This repo was cloned from one on another server (the server I use to \n> > backup everything) with a git clone command:\n> \n> Yeah. Normally you'd (well, _I_ would) only push to bare repositories, and \n> normally you wouldn't make those bare repositories have \"remotes\" entries, \n> which is why you're the first to apparently even notice this insanity.\n> \n> It wasn't your fault, it's simply bad defaults for git behaviour.\n> \n> The behaviour for \"git pull\" has improved _immensely_ over the last few \n> months, but \"git push\" still does the same thing it always did, because \n> fewer people care about pushing than pulling, and because the old \"git \n> push\" behaviour of just updating all the branches in common actually \n> happens to be the right thing when you do *not* make the central \n> repository contain remote branches of its own.\n> \n> > Based on all this, what is the correct way to update my core repo on my \n> > server? (I'm sorry - I'm pretty new to git, so I haven't quite cottoned on \n> > to some aspects yet).\n> \n> With the current git model, I would suggest:\n> \n> - for \"central\" repositories, use a bare repository, and don't create \n> \"remotes\" branches in that central repository at all.\n> \n> - for other repositories, don't push into them, just _pull_ into them \n> (because that also knows about updating the working tree etc: pushing \n> is really meant to be done only into bare and central ones that don't \n> actually have any work happening in them, and _cannot_ have any work \n> happening in them because they don't even have a working directory \n> associated with them)\n> \n> That said, I don't think that's necessarily the right answer in the longer \n> run. It's how git people do things, but it's not necessarily the *best* \n> way of doing things. I think the better solution in the longer term is to \n> simply improve how \"git push\" works:\n> \n> - we should probably do the same kinds of .git/config file entries for \n> pushing as we do for fetching, and just get rid of the old implicit \n> model, and instead have a nice refspec pattern model for what gets \n> pushed instead.\n> \n> I _think_ the refspec cleanup work by Daniel makes this something we \n> can almost already do. Daniel?\n> \n> - we should also likely have some way to specify what happens when you \n> push into a branch that is currently checked out and has a working tree \n> associated with it.\n> \n> This was briefly discussed a few weeks ago, but nobody cared enough, I \n> suspect.\n> \n> anyway, I think the _proper_ thing to do would be to associate each \n> [remote] entry in the config file with a \"push\" refspec pattern, the way \n> we do for \"fetch\" already.\n> \n> Linux\n\n\nJust so you don't think I'm completely crazy, I'll explained what caused \nthis:\n\nI first created a repo on machine B by initializing a blank repo, then \nfetching all historic revisions using git-svn from svn. Then I cloned the \nrepo to machine A using a git clone. Once I had the clone on machine A, I \ninitialized a new repo on machine B by doing a git clone from the repo on \nmachine A, so that the remote branches would point to the right place so a \ngit push would work. I see now that that caused a problem because the \nrepo on machine A now has remote branches pointing to machine B, which \nisn't right because that repo doesn't exist anymore.\n\nBased on what you've said, it seems like I should be initialising a blank \nrepo on machine A, then pushing from machine B to machine A, rather than \ncloning on A from B.\n\nAt this point would it just be sensible to delete the remote branches on \nmachine A?\n\nAlex\n"},{"id":"44860","messageId":"alpine.LFD.0.98.0706121144050.14121@woody.linux-foundation.org","threadId":"8564","inReplyTo":"Pine.LNX.4.64.0706121309260.7703@www.mintpixels.com","subject":"Re: Problem with a push","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-12T18:46:41Z","receivedAt":"2007-06-12T18:46:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 12 Jun 2007, Alex R.M. Turner wrote:\n> \n> Based on what you've said, it seems like I should be initialising a blank \n> repo on machine A, then pushing from machine B to machine A, rather than \n> cloning on A from B.\n\nThat's generally what you'd do for a central repo, yes.\nBut:\n\n> At this point would it just be sensible to delete the remote branches on \n> machine A?\n\nYes, in the current environment, the easiest thing to do is to just remove \nthose branches.\n\nOR, alternatively, just keep them, but on machine B, make your .git/config \nfile have something like\n\n\t[remote \"origin\"]\n\t\turl = ssh://aturner@svn.mintpixels.com/data/git/mls\n\t\tfetch = +refs/heads/*:refs/remotes/origin/*\n\t\tpush = refs/heads/*:refs/heads/*\n\nwhich should just make it clear to \"git push\" than when you push from B to \n\"origin\", you should push everything under \"refs/heads\" (assuming that's \nwhat you want, of course)-\n\n\n\t\tLinus\n"},{"id":"44868","messageId":"1181679304.12616.30.camel@ld0161-tx32","threadId":"8564","inReplyTo":"alpine.LFD.0.98.0706111727240.14121@woody.linux-foundation.org","subject":"Re: Problem with a push","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2007-06-12T20:15:04Z","receivedAt":"2007-06-12T20:15:04Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Mon, 2007-06-11 at 19:40, Linus Torvalds wrote:\n> That said, I don't think that's necessarily the right answer in the longer \n> run. It's how git people do things, but it's not necessarily the *best* \n> way of doing things. I think the better solution in the longer term is to \n> simply improve how \"git push\" works:\n> \n> - we should probably do the same kinds of .git/config file entries for \n> pushing as we do for fetching, and just get rid of the old implicit \n> model, and instead have a nice refspec pattern model for what gets \n> pushed instead.\n\nYeah, the other day I was baffled briefly by the fact that\nI added a remote to my config using \"git remote add ...\"\nwith the intent of using it for pushing to a publishing site.\nI forgot that it set up fetch only refs.\n\nMaybe a new \"--push\" flag to 'git remote add --push ...\"\nto indicated the intended flow direction for a remote?\n\n> anyway, I think the _proper_ thing to do would be to associate each \n> [remote] entry in the config file with a \"push\" refspec pattern, the way \n> we do for \"fetch\" already.\n\nnod\n\njdl\n"},{"id":"44879","messageId":"46a038f90706121638l2bcc613fue6446750d2db651f@mail.gmail.com","threadId":"8564","inReplyTo":"7vk5u9hzv9.fsf@assigned-by-dhcp.pobox.com","subject":"Re: Problem with a push","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-12T23:38:30Z","receivedAt":"2007-06-12T23:38:30Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/13/07, Junio C Hamano wrote:\n> - When doing 'matching refs', do it only under refs/heads/.\n\nYes please ;-)\n\nWe've had this conversation about 2 weeks ago -- it's confusing (and\nworrying) to see that a git-push tries to push stuff from remotes/ to\nthe repo...\n\ncheers,\n\nmartin\n"},{"id":"46206","messageId":"7v7ipj1s5z.fsf_-_@assigned-by-dhcp.cox.net","threadId":"8564","inReplyTo":"7vk5u9hzv9.fsf@assigned-by-dhcp.pobox.com","subject":"[PATCH] \"git-push $URL\" without refspecs pushes only matching branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-02T02:00:08Z","receivedAt":"2007-07-02T02:00:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When \"git push\" is run without any refspec (neither on the\ncommand line nor in the config), we used to push \"matching refs\"\nin the sense that anything under refs/ hierarchy that exist on\nboth ends were updated. This used to be a sane default for\npublishing your repository to another back when we did not have\nrefs/remotes/ hierarchy, but it does not make much sense these\ndays.\n\nThis changes the semantics to push only \"matching branches\".\n\nSigned-off-by: Junio C Hamano \n---\n Junio C Hamano writes:\n\n > Probably we should not do push anything other than refs/heads/\n > when we do \"matching refs\"\n >\n > I think what we might want to do around this area are:\n >\n > - Don't change anything, if the command line says refspec, or\n > the remote has push refspec specified.\n >\n > - When doing 'matching refs', do it only under refs/heads/.\n >\n > - Ship with a receive-pack hook that attempts a 3-way merge\n > update when the currently checked out branch is updated.\n >\n > Additionally we can give an option to \"git clone\" (or \"git\n > remote add\") to arrange the cross-push configuration for\n > mothership-satellite Andy showed in the clone's .git/config;\n > but I think that is a separate issue.\n\n remote.c | 7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/remote.c b/remote.c\nindex 500ca4d..cf98a44 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -544,6 +544,13 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,\n \t\t\tif (!pat)\n \t\t\t\tcontinue;\n \t\t}\n+\t\telse if (prefixcmp(src->name, \"refs/heads/\"))\n+\t\t\t/*\n+\t\t\t * \"matching refs\"; traditionally we pushed everything\n+\t\t\t * including refs outside refs/heads/ hierarchy, but\n+\t\t\t * that does not make much sense these days.\n+\t\t\t */\n+\t\t\tcontinue;\n \n \t\tif (pat) {\n \t\t\tconst char *dst_side = pat->dst ? pat->dst : pat->src;\n"}]}