{"thread":{"id":"19915","subject":"[Q] `git push', branch management, and \"(forced update)\"?","startedAt":"2009-06-24T08:34:18Z","lastAt":"2009-06-24T16:31:11Z","messageCount":2,"participants":["Brian Foster","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"116856","messageId":"200906241034.18550.brian.foster@innova-card.com","threadId":"19915","inReplyTo":null,"subject":"[Q] `git push', branch management, and \"(forced update)\"?","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2009-06-24T08:34:18Z","receivedAt":"2009-06-24T08:34:18Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":"Hello,\n\n A colleague of mine will be asking for my help when he\n returns later this week, and I'm not too certain what's\n going on. My instant reaction is what he's doing may not\n be a good idea (an example of rebasing a branch that others\n pull, which I understand should be avoided). However, I'm\n not a gitpert, and am also sufficiently confused it's worth\n asking for help/advice. My apologies for the length....\n\n What we have is four (4) repositories, L, B, R, and M:\n\n L is my colleague's (local) working repository.\n B is a bare repository.\n R is one (or more?) remote repositories.\n M is a bare repository.\n\n The model is work is done in R, patches are sent (by e-mail)\n to my colleague, who applies them to L, often does some fixes\n (in L), pushes the resultant applied-patch-plus-fixes to B;\n and R pulls every now and then from B. The cycle repeats.\n (M, as such, does not enter the picture at this point.)\n\n More specifically, what my colleague does (I think, I may\n not have this completely correct) is apply the patches to\n a topic branch TOPIC. His fixes are separate commits, also\n on TOPIC, so (in theory) TOPIC grows in a nice linear manner\n (`r' came from R via e-mail, `f' is a local fix):\n\n o--o--o--o master\n \\\n r--r--f--f TOPIC\n\n L is a clone of M, where other work has also been committed,\n in master. So now-and-then my colleague pulls M into L:\n\n o--o--o--o--*--* master\n \\\n r--r--f--f TOPIC\n\n My colleague then pushes the result to B. End result is B\n is essentially M plus TOPIC.\n\n As it happens (mostly by design), the changes on TOPIC\n are independent of the `*' ones on master. So, working\n in L, my colleague often rebases, and this is (always?)\n a fast-forward:\n\n o--o--o--o--*--* master\n \\\n r--r--f--f TOPIC\n\n He now wants to push that structure to B, so that R can\n later pull the updated world. Based on some experiments,\n he does (in L):\n\n $ git checkout master\n $ git push --tags ssh://.../B.git +:\n\n (I'm not sure why he is using `--tags', or `+:' instead\n of a simple `:') but reports what happens is the `push'\n gets the error(?):\n\n fatal: remote part of refspec is not a valid name in +:\n\n Given that `git help push' (1.6.2.2) lists/describes the\n `+:' , I'm (extra) baffled. What's going on?\n\n Each of the repositories L, B, R, and M are on different\n machines, and it is highly probable different versions of\n git are being used.\n\n In a simple simulation test I tried, it not only worked\n for me, but the subsequent pull from simulated-B into\n simulated-R said the TOPIC was a \"(forced update)\".\n What does that mean?\n\n And what is it my colleague should consider doing (or,\n reading?)?\n\n Again, apologies for the length!\n\ncheers,\n\t-blf-\n\n-- \n“How many surrealists does it take to | Brian Foster\n change a lightbulb? Three. One calms | somewhere in south of France\n the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.” | http://www.stopesso.com\n"},{"id":"116867","messageId":"7v8wjhwq40.fsf@alter.siamese.dyndns.org","threadId":"19915","inReplyTo":"200906241034.18550.brian.foster@innova-card.com","subject":"Re: [Q] `git push', branch management, and \"(forced update)\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-24T16:31:11Z","receivedAt":"2009-06-24T16:31:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Foster writes:\n\n> L is a clone of M, where other work has also been committed,\n> in master. So now-and-then my colleague pulls M into L:\n>\n> o--o--o--o--*--* master\n> \\\n> r--r--f--f TOPIC\n>\n> My colleague then pushes the result to B. End result is B\n> is essentially M plus TOPIC.\n>\n> As it happens (mostly by design), the changes on TOPIC\n> are independent of the `*' ones on master. So, working\n> in L, my colleague often rebases, and this is (always?)\n> a fast-forward:\n>\n> o--o--o--o--*--* master\n> \\\n> r--r--f--f TOPIC\n\nWhen he rebases the TOPIC, he is not making this topology.\nInstead, this is what he is making:\n\n r'-r'-f'-f' TOPIC\n /\n o--o--o--o--*--* master\n \\\n r--r--f--f\n\nThe tip of the TOPIC before (the rightmost commit on the lower side branch\nin this picture) is not an ancestor of the tip of the TOPIC after the\nrebase. It is not a fast-forward.\n\n> In a simple simulation test I tried, it not only worked\n> for me, but the subsequent pull from simulated-B into\n> simulated-R said the TOPIC was a \"(forced update)\".\n> What does that mean?\n\nThe remote side B (and its mirror R) still points at the rightmost commit\non the lower side branch with TOPIC. He forces a non-fast-forward push to\nB using \"+:\" (that is \"leading plus to force a push\" followed by \"solitary\ncolon to mean push matching refs\"), violating a simple rule \"do not rebase\nwhat others already have seen\". Push from B to its mirror R then will be\nin the same situation.\n\nThis may be a good food-for-thought:\n\n http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html\n\nIncidentally the message explains why it would be bad if your\n\"now-and-then\" above is too often.\n"}]}