{"thread":{"id":"28466","subject":"What's The Right Way to Do This?","startedAt":"2011-09-23T04:48:36Z","lastAt":"2011-09-23T18:13:06Z","messageCount":6,"participants":["Jon Forrest","Michael Witten","Luke Diamand","Johannes Sixt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"176040","messageId":"loom.20110923T064720-366@post.gmane.org","threadId":"28466","inReplyTo":null,"subject":"What's The Right Way to Do This?","fromName":"Jon Forrest","fromEmail":"nobozo@gmail.com","sentAt":"2011-09-23T04:48:36Z","receivedAt":"2011-09-23T04:48:36Z","isPatch":false,"sender":{"key":"nobozo@gmail.com","avatar":"https://gravatar.com/avatar/37c6a7b57f29b3f35c6a9016537907c52f15bbf98575617dc046bcec6bf06372?d=mp&s=160"},"body":"I'm just now starting to use git for more than trivial things.\nToday I got myself in trouble. Here's what happened:\n\n1) I pulled the master branch from the IT repository from our\nmain git server.\n\n2) I created a branch from this called \"J\" and started making changes.\n\n3) Other people pulled master from IT and then pushed changes back.\n\n4) I merged J with my master branch.\n\n5) I tried pushing my master back to origin but this failed with\nthe usual message saying I first needed to pull from origin.\nSo, I pulled and then pushed. This worked.\n\n6) On another server where I was going to use my changes I pulled\nmaster from IT.\n\n6) It turned out that my changes were incorrect. So, I tried to revert\nusing various methods I found by googling \"git revert\". What happened\nwas that when I tried to revert back to the commit before the one I\nmade, the files I had modified *and* the files that apparently were\nmodified by other people in #3 above were reverted. This wasn't what\nI wanted. I only wanted to revert the changes I had made.\n\nWith the help of someone more experienced than me we were able to get\nthings back to normal but this experience left me wondering what I\nshould have done in the first place. There's a chance I'm going to\nhave to go through all this again as I try to fix the problem with\nmy changes.\n\nAny suggestions would be appreciated.\n\nThanks,\nJon Forrest \n"},{"id":"176042","messageId":"CAMOZ1BtTi7GxwTvPTEtHoV-GspAZKJiLauXfkwBFJk+RZJT_7A@mail.gmail.com","threadId":"28466","inReplyTo":"loom.20110923T064720-366@post.gmane.org","subject":"Re: What's The Right Way to Do This?","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-23T05:08:40Z","receivedAt":"2011-09-23T05:08:40Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Sep 23, 2011 at 04:48, Jon Forrest <nobozo@gmail.com> wrote:\n\n> ... So, I tried to revert using various methods I found by\n> googling \"git revert\"...\n> ...\n> ...this experience left me wondering what I should have\n> done in the first place.\n\nWhat you should have done in the first place is RTFM; while\nnot fantastic, there is a decent amount of official git\ndocumentation.\n\n> What happened was that when I tried to revert back to the\n> commit before the one I made, the files I had modified\n> *and* the files that apparently were modified by other\n> people in #3 above were reverted. This wasn't what\n> I wanted. I only wanted to revert the changes I had made.\n\nIt would be a good idea to reproduce the unexpected behavior\nyou are experiencing by means of a minimal set of commands\nthat you can post here for others to try.\n\n> With the help of someone more experienced than me we were\n> able to get things back to normal... There's a chance I'm\n> going to have to go through all this again as I try to fix\n> the problem with my changes.\n\nWhy don't you ask that person about it?\n"},{"id":"176045","messageId":"4E7C27A0.9030900@diamand.org","threadId":"28466","inReplyTo":"loom.20110923T064720-366@post.gmane.org","subject":"Re: What's The Right Way to Do This?","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2011-09-23T06:30:56Z","receivedAt":"2011-09-23T06:30:56Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"On 23/09/11 05:48, Jon Forrest wrote:\n> I'm just now starting to use git for more than trivial things.\n> Today I got myself in trouble. Here's what happened:\n>\n> 1) I pulled the master branch from the IT repository from our\n> main git server.\n>\n> 2) I created a branch from this called \"J\" and started making changes.\n>\n> 3) Other people pulled master from IT and then pushed changes back.\n>\n> 4) I merged J with my master branch.\n\nSomeone will be along soon to correct me, but I think you should have \nrebased against the master branch rather than merged. Something like:\n\n% git rebase origin\n\nThat way your changes would remain appended to the tip of the master \nbranch. That will in general make your life much easier for all sorts of \nreasons.\n\n>\n> 5) I tried pushing my master back to origin but this failed with\n> the usual message saying I first needed to pull from origin.\n> So, I pulled and then pushed. This worked.\n>\n> 6) On another server where I was going to use my changes I pulled\n> master from IT.\n>\n> 6) It turned out that my changes were incorrect. So, I tried to revert\n> using various methods I found by googling \"git revert\". What happened\n> was that when I tried to revert back to the commit before the one I\n> made, the files I had modified *and* the files that apparently were\n> modified by other people in #3 above were reverted. This wasn't what\n> I wanted. I only wanted to revert the changes I had made.\n\nAt a guess, git revert created a commit that undid your _merge_, rather \nthan your commit. The merge included all those other changes....\n\nIt's a good idea to take a look at what a commit does before pushing it \n- \"git show HEAD\" is your friend.\n\n>\n> With the help of someone more experienced than me we were able to get\n> things back to normal but this experience left me wondering what I\n> should have done in the first place. There's a chance I'm going to\n> have to go through all this again as I try to fix the problem with\n> my changes.\n\nUse git rebase (*) to keep your changes nicely arranged at the top of \nthe main branch.\n\nUse git show to check the sanity of what you're about to push upstream.\n\nI think you could award yourself a nice cup of tea after an experience \nlike that though, having been on both sides of it, I can imagine you \nneed it :-P\n\nRegards!\nLuke\n\n\n(*) But note that rebasing can cause problems for people who are \ndownstream of _you_. See the  git-rebase(1) man page.\n"},{"id":"176046","messageId":"4E7C29BA.5030403@viscovery.net","threadId":"28466","inReplyTo":"loom.20110923T064720-366@post.gmane.org","subject":"Re: What's The Right Way to Do This?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-09-23T06:39:54Z","receivedAt":"2011-09-23T06:39:54Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 9/23/2011 6:48, schrieb Jon Forrest:\n> I'm just now starting to use git for more than trivial things.\n> Today I got myself in trouble. Here's what happened:\n> \n> 1) I pulled the master branch from the IT repository from our\n> main git server.\n> \n> 2) I created a branch from this called \"J\" and started making changes.\n> \n> 3) Other people pulled master from IT and then pushed changes back.\n\nOK, so you are basically using a central repo.\n\n> 4) I merged J with my master branch.\n> \n> 5) I tried pushing my master back to origin but this failed with\n> the usual message saying I first needed to pull from origin.\n> So, I pulled and then pushed. This worked.\n> \n> 6) On another server where I was going to use my changes I pulled\n> master from IT.\n\nI assume you mention this because with this step you detected that your\nchanges were crap.\n\n> 6) It turned out that my changes were incorrect. So, I tried to revert\n> using various methods I found by googling \"git revert\". What happened\n> was that when I tried to revert back to the commit before the one I\n> made, the files I had modified *and* the files that apparently were\n> modified by other people in #3 above were reverted. This wasn't what\n> I wanted. I only wanted to revert the changes I had made.\n\nIt looks like you had reset the history, not just reverted your changes.\n\n> With the help of someone more experienced than me we were able to get\n> things back to normal but this experience left me wondering what I\n> should have done in the first place. There's a chance I'm going to\n> have to go through all this again as I try to fix the problem with\n> my changes.\n\nWith a central repository, any push into it marks a \"done deal\". No matter\nhow wrong and bogus your changes are, as soon as you push them into the\ncentral repository, they are cast in stone.\n\nAt this point, the best you can do is to revert you changes, and by this I\nmean that you create and push out another commit on top that backs out the\nchanges that you made.\n\nIf this is not what you (or your team) wants, than the problem is not with\nsuboptimal use of the git toolset, but with the push policy within you\nteam. A good policy should forbid that untested stuff can be pushed into\nthe central repository.\n\nMy suggestion is that you find a way to move your changes to the test site\n(the \"another server\" you mention in step 6) without going through the\ncentral repository. For example, if you have ssh access between your\ndevelopment machine and the test site, you can push or pull your changes\nbetween them directly.\n\n-- Hannes\n"},{"id":"176066","messageId":"4E7C8D77.4020707@gmail.com","threadId":"28466","inReplyTo":"4E7C27A0.9030900@diamand.org","subject":"Re: What's The Right Way to Do This?","fromName":"Jon Forrest","fromEmail":"nobozo@gmail.com","sentAt":"2011-09-23T13:45:27Z","receivedAt":"2011-09-23T13:45:27Z","isPatch":false,"sender":{"key":"nobozo@gmail.com","avatar":"https://gravatar.com/avatar/37c6a7b57f29b3f35c6a9016537907c52f15bbf98575617dc046bcec6bf06372?d=mp&s=160"},"body":"On 9/22/2011 11:30 PM, Luke Diamand wrote:\n\n> Someone will be along soon to correct me, but I think you should have\n> rebased against the master branch rather than merged. Something like:\n>\n> % git rebase origin\n>\n> That way your changes would remain appended to the tip of the master\n> branch. That will in general make your life much easier for all sorts of\n> reasons.\n\nIn considering this, I'm having trouble understanding when to do a merge\nas opposed to a rebase. Let's say that other people weren't putting\nchanged back in the remote master. So, my changes would always be at the\ntip. Is that when I should merge? If so, then this suggest that knowing\nwhat to do depends on knowing what other people are doing. But, doesn't\nthis go against the philosophy of a distributed SCM?\n\n> At a guess, git revert created a commit that undid your _merge_, rather\n> than your commit. The merge included all those other changes....\n>\n> It's a good idea to take a look at what a commit does before pushing it\n> - \"git show HEAD\" is your friend.\n\nIIRC, I did this and I saw the collection of the changes I had\nmade plus what other people had made. I didn't know how to revert\nonly my changes.\n\n> Use git rebase (*) to keep your changes nicely arranged at the top of\n> the main branch.\n\nThanks. I'll study up on this.\n\n> I think you could award yourself a nice cup of tea after an experience\n> like that though, having been on both sides of it, I can imagine you\n> need it :-P\n\nIt certainly wasn't my finest hour!\n\nJon\n"},{"id":"176081","messageId":"7vr537unyl.fsf@alter.siamese.dyndns.org","threadId":"28466","inReplyTo":"loom.20110923T064720-366@post.gmane.org","subject":"Re: What's The Right Way to Do This?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-23T18:13:06Z","receivedAt":"2011-09-23T18:13:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Forrest <nobozo@gmail.com> writes:\n\n> I'm just now starting to use git for more than trivial things.\n> Today I got myself in trouble. Here's what happened:\n>\n> 1) I pulled the master branch from the IT repository from our\n> main git server.\n>\n> 2) I created a branch from this called \"J\" and started making changes.\n>\n> 3) Other people pulled master from IT and then pushed changes back.\n>\n> 4) I merged J with my master branch.\n>\n> 5) I tried pushing my master back to origin but this failed with\n> the usual message saying I first needed to pull from origin.\n> So, I pulled and then pushed. This worked.\n>\n> 6) On another server where I was going to use my changes I pulled\n> master from IT.\n\nUp to this point you are doing perfectly fine as far as I can tell.\n\n> 6) It turned out that my changes were incorrect. So, I tried to revert\n> using various methods I found by googling \"git revert\". What happened\n> was that when I tried to revert back to the commit before the one I\n> made,...\n\nNow, in git you do not \"revert back TO the commit\".  You could reset back\nto the commit but that is to discard everything that is done since that\ncommit.\n\nImagine this history (time flows from left to right).\n\nAt point 4, 'master' in your working repository is at M, and you haven't\nseen others' work 'o' yet:\n\n    ---M---o---o---o (others' work)\n        \\\n         x---y---z (your work on J branch)\n\nYou merge your work your master and then your 'master' now points at 'z'.\n\nIf you push and replace 'master' at the central repository with your\n'master', others' work 'o' will be lost. So you pulled in point 5 to make\nthe history look like this:\n\n    ---M---o---o---o (others' work)\n        \\           \\\n         x---y---z---X\n\nYou pulled to grab these 'o' commits, and made a merge with your master\n(now at J) to create 'X', and then pushed it as 'master' at the central\nrepository.\n\nTime passes and there may be more changes on top of 'X' now and the\ncurrent tip of the shared 'master' may be 'A'.\n\n    ---M---o---o---o (others' work)\n        \\           \\\n         x---y---z---X---o---o---A\n\nEven if the changes 'x', 'y', and 'z' later turns out to be unwanted, you\ndo not want discard others' work 'o'. Rewinding the history to make the\n'master' point at 'M' is not what you want.\n\nInstead, you would make commits that revert the effect of them on top of\nthe current history. That is what \"git revert\" does.\n\n\n    ---M---o---o---o (others' work)\n        \\           \\\n         x---y---z---X---o---o---A-(z)-(y)-(x)\n\nThat is, on top of 'A', you would run \"git revert z\" to create an \"anti-z\"\ncommit \"(z)\" to cancel the effect of 'z', and do the same for y and x, to\neradicate them.\n\nAnother possibility is to revert the merge 'X', but I'll leave it as an\nadvanced exercise to the readers.\n"}]}