{"thread":{"id":"2333","subject":"Now What?","startedAt":"2005-11-03T01:30:37Z","lastAt":"2005-11-06T20:33:18Z","messageCount":20,"participants":["Jon Loeliger","Chris Shoemaker","Junio C Hamano","Peter Eriksen","Daniel Barkalow","Linus Torvalds","Josef Weidendorfer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11053","messageId":"E1EXTw5-00063o-Gt@jdl.com","threadId":"2333","inReplyTo":null,"subject":"Now What?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-11-03T01:30:37Z","receivedAt":"2005-11-03T01:30:37Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"\nThe Other Day, I offered to help write up some parts of\na \"Something weird just happened.  Now What?\" document.\n\nSo, I'm now soliciting suggestions and/or tips that can\nbe thrown together to form the basis of that document.\n\nI have a few ideas and a rough outline up my sleeve, but\nI am curious to know what _you_ think needs to be covered.\n\nI think one of the most crucial aspects that needs to be\ncovered well is the \"Merge Failed\" problem.  So, for starters,\nI'd like to get your suggestions on this particular issue.\nI know when I see the dreaded \"merge by hand\" message I\noften sit and stare, pondering \"Now what?\"\n\nI feel that an explanation of all of the behind-the-scripts-\nin-.git communication files is needed.  In particular these:\n\n    FETCH_HEAD\n    MERGE_HEAD\n    LAST_MERGE\n    MERGE_MSG\n\nThese need to be mentioned and explained because they\nfrequently form exactly the critical missing link or\nstarting point after a failed fetch or merge.\n\nFinally, a procedure or style question.  Should this\nwrite-up be in the form of a structured FAQ?  A stand-alone\nexpository document?\n\nThanks,\njdl\n"},{"id":"11054","messageId":"20051103014307.GA1988@pe.Belkin","threadId":"2333","inReplyTo":"E1EXTw5-00063o-Gt@jdl.com","subject":"Re: Now What?","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2005-11-03T01:43:07Z","receivedAt":"2005-11-03T01:43:07Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Wed, Nov 02, 2005 at 07:30:37PM -0600, Jon Loeliger wrote:\n> \n> The Other Day, I offered to help write up some parts of\n> a \"Something weird just happened.  Now What?\" document.\n> \n> So, I'm now soliciting suggestions and/or tips that can\n> be thrown together to form the basis of that document.\n> \n> I have a few ideas and a rough outline up my sleeve, but\n> I am curious to know what _you_ think needs to be covered.\n\n\"I cloned a remote repo. Then I pulled a branch from the remote repo\nand it started changing all the these files.  I paniced and hit\nctrl-c.  Doh!  I should have checked out the branch locally before\npulling.  Now what?  How can I recover without cloning the repo\nagain?\"\n\nIn general, for each common operation, it'd be nice to explain how to\n\"undo\". \n\n-chris\n"},{"id":"11061","messageId":"20051103083840.GA28300@ebar091.ebar.dtu.dk","threadId":"2333","inReplyTo":"E1EXTw5-00063o-Gt@jdl.com","subject":"Re: Now What?","fromName":"Peter Eriksen","fromEmail":"s022018@student.dtu.dk","sentAt":"2005-11-03T08:38:40Z","receivedAt":"2005-11-03T08:38:40Z","isPatch":false,"sender":{"key":"s022018@student.dtu.dk","avatar":null},"body":"On Wed, Nov 02, 2005 at 07:30:37PM -0600, Jon Loeliger wrote:\n...\n> I think one of the most crucial aspects that needs to be\n> covered well is the \"Merge Failed\" problem.  So, for starters,\n> I'd like to get your suggestions on this particular issue.\n> I know when I see the dreaded \"merge by hand\" message I\n> often sit and stare, pondering \"Now what?\"\n\nHere's one I've done too many times:\n\n~/git/git-core]cat .git/remotes/origin\nURL: git://git.kernel.org/pub/scm/git/git.git\nPull: master:origin\n\n~/git/git-core]git-checkout maint\n~/git/git-core]git pull\nUnpacking 222 objects\n 100% (222/222) done\n* committish: 9534f40bc42dd826cc26c8c8c84f6a8a5fc569f6\n  branch 'master' of git://git.kernel.org/pub/scm/git/git\n* refs/heads/origin: storing branch 'master' of\n* git://git.kernel.org/pub/scm/git/git\nTrying really trivial in-index merge...\nfatal: Merge requires file-level merging\nNope.\nTrying simple merge.\nSimple merge failed, trying Automatic merge.\nAuto-merging Documentation/tutorial.txt.\nAuto-merging Makefile.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in Makefile.\nAuto-merging apply.c.\nAuto-merging cache.h.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in cache.h.\nAuto-merging clone-pack.c.\nAuto-merging connect.c.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in connect.c.\nAuto-merging daemon.c.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in daemon.c.\nAuto-merging debian/changelog.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in debian/changelog.\nAuto-merging fetch-pack.c.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in fetch-pack.c.\nAuto-merging git-branch.sh.\nAuto-merging git-checkout.sh.\nAuto-merging git-clone.sh.\nAuto-merging git-cvsimport.perl.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in git-cvsimport.perl.\nAuto-merging git-fetch.sh.\nAuto-merging git-parse-remote.sh.\nAuto-merging git-tag.sh.\nAuto-merging quote.c.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in quote.c.\nAuto-merging quote.h.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in quote.h.\nAuto-merging refs.c.\nAuto-merging rev-list.c.\nAuto-merging send-pack.c.\nAuto-merging sha1_name.c.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in sha1_name.c.\nAuto-merging upload-pack.c.\nmerge: warning: conflicts during merge\nERROR: Merge conflict in upload-pack.c.\nfatal: merge program failed\nAutomatic merge failed; fix up by hand\n\nIndeed, what now?\n\nRegards,\n\nPeter\n"},{"id":"11060","messageId":"7vvezajeet.fsf@assigned-by-dhcp.cox.net","threadId":"2333","inReplyTo":"E1EXTw5-00063o-Gt@jdl.com","subject":"Re: Now What?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-03T08:58:50Z","receivedAt":"2005-11-03T08:58:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\n> I feel that an explanation of all of the behind-the-scripts-\n> in-.git communication files is needed.  In particular these:\n>\n>     FETCH_HEAD\n>     MERGE_HEAD\n>     LAST_MERGE\n>     MERGE_MSG\n>\n> These need to be mentioned and explained because they\n> frequently form exactly the critical missing link or\n> starting point after a failed fetch or merge.\n\nI am not so sure if it would help to know details of the above\nfour files to answer \"Now What\" question, but I'll try to\ndescribe them near the end of this message.\n\nBefore that, here is a cookbook failed pull/merge resolution\nprocedure.\n\n\t$ git pull some-where\n\tGaah ... resolve by hand.\n\nOops, it failed.  Now what?\n\nFirst, if your index did not match your HEAD before\npulling/merging, the merge strategies will refuse to merge in\nthe changes and would fail without touching your working tree\n(so you would not even see \"resolve by hand\" message).  If you\nwant to proceed, you need to somehow match your HEAD and your\nindex to retry.  There are two possibilities.\n\n(1) if you were deep in a middle of something, snapshot your\n    changes and rewind the current tree.\n\n\t$ git commit -a -m 'WIP'\n\t$ git branch save-wip\n        $ git reset --hard HEAD^\n\n    and then retry merge or pull.  Later you would want to\n    resurrect what you did from save-wip branch (e.g. \"git diff\n    save-wip^ save-wip | git apply\" after finishing your\n    merge).\n\n(2) if you did not have much worth saving, just rewind the\n    changes.  Optionally you could save the diff just in case.\n\n\t$ git diff HEAD >tmp-wip.diff\n        $ git reset --hard\n\n    and then retry merge or pull.\n\nNow that case is out of our way, I'll discuss the case where\nyour index did match your HEAD from here on.  You pulled from\nremote, merge strategy tried to do its work, and did not find a\nclean automerge.\n\nAt this point, the automerge procedure would have already\nupdated your index for paths that cleanly merged.  The rest are\nleft in your working tree, so this diff would show what remains\nto be resolved:\n\n        $ git diff\n\nYou would most likely see some <<<< ==== >>>> conflict markers.\nResolving them by hand is hopefully something familiar to CVS or\nSVN migrants, so \"Now what\" document may not have to talk about\nwhat these conflict markers mean (\"between <<<< and ==== are\nyour version, between ==== and >>>> are their version\", or\nsomething like that --- I may be getting this particular detail\nwrong in this sentence, so you should check).\n\nAfter resolving them by hand, you would want to see what got\nchanged from _your_ version for sanity checking, because you are\nhopefully more familiar with your version than theirs, and\nreading diff between theirs might be more difficult.  So check\n\n\t$ git diff HEAD\n\nto see what changes this pull brought in, including the conflict\nresolution you just did.  On the other hand,\n\n\t$ git diff MERGE_HEAD\n\nwould show diff from their head, so you would see what you did\nto their tree.\n\nAfter checking the diffs, if things look OK, compiling and\ntesting is the same procedure as you would normally do before\nmaking any commit.  Then\n\n\t$ git commit -a\n\n(as usual, you can drop '-a' if you manually 'git-update-index'\nall the necessary paths before this step) would give you the\nregular commit message editor, with a reminder \"you are\ncommitting a merge\", with prepared message \"merge from\nsome-where repository\".  Edit it and exit the editor normally to\nmake the merge commit, and you are done.\n\nNow to the communication files.\n\n>     FETCH_HEAD\n\nThis file lists refs the git-fetch command (run from git-pull)\nretrieved from the remote.  Usually it marks everything but one\nas 'not-for-merge'.  The one that is not marked as\n'not-for-merge' is the commit you are merging into the current\nhead.  This is not looked at by the merge machinery, but\ngit-pull uses it to decide which commits to pass to git-merge.\n\n>     MERGE_HEAD\n\nThis is present only after a failed automerge, by git-merge, and\nlists the commits that you are merging into the current head\n(typically only one) -- the same as the ones not marked as\n'not-for-merge' in FETCH_HEAD, because this file records the\ncommits given to git-merge.\n\n>     LAST_MERGE\n\nThis is more or less historical curiosity and only git-resolve\nuses it.  Records almost the same information as MERGE_HEAD.\n\n>     MERGE_MSG\n\nThis is created by git-pull from FETCH_HEAD to format a human\nreadable autocommit log.\n\n> Finally, a procedure or style question.  Should this\n> write-up be in the form of a structured FAQ?  A stand-alone\n> expository document?\n\nOne useful thing would be to have a cut&paste ready example that\nwould cover constructing two branches/repos, pulling a branch\nfrom one to the other and causing an actual conflict, and show\nhow to resolve it and make a commit, in a section in Tutorial.\nI think we already have something like that there.\n\nAnother good thing would be, after proofreading this message and\nmaking necessary corrections, send it as a patch form to add it\nas a new file under Documentation/howto/.\n"},{"id":"11062","messageId":"7vpspijeba.fsf@assigned-by-dhcp.cox.net","threadId":"2333","inReplyTo":"20051103014307.GA1988@pe.Belkin","subject":"Re: Now What?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-03T09:00:57Z","receivedAt":"2005-11-03T09:00:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Shoemaker <c.shoemaker@cox.net> writes:\n\n> \"I cloned a remote repo. Then I pulled a branch from the remote repo\n> and it started changing all the these files.  I paniced and hit\n> ctrl-c.  Doh!  I should have checked out the branch locally before\n> pulling.  Now what?  How can I recover without cloning the repo\n> again?\"\n\nAlthough I am not sure what this example is about,...\n\n> In general, for each common operation, it'd be nice to explain how to\n> \"undo\". \n\nI think this makes sense.\n"},{"id":"11063","messageId":"7v4q6uhx0a.fsf@assigned-by-dhcp.cox.net","threadId":"2333","inReplyTo":"20051103083840.GA28300@ebar091.ebar.dtu.dk","subject":"Re: Now What?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-03T10:00:05Z","receivedAt":"2005-11-03T10:00:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Peter Eriksen\" <s022018@student.dtu.dk> writes:\n\n> Here's one I've done too many times:\n>\n> ~/git/git-core]cat .git/remotes/origin\n> URL: git://git.kernel.org/pub/scm/git/git.git\n> Pull: master:origin\n>\n> ~/git/git-core]git-checkout maint\n> ~/git/git-core]git pull\n\nYou are merging my master into your \"maint\", probably a copy of\nmy (previous) maint.\n\nWhat now?  Depends on what you wanted to do.  If what you wanted\nto do was to merge my \"master\" to your \"maint\", then you would\nresolve the conflicts by hand, but probably that was not what\nyou wanted to do.\n\nAfter that pull, your repository is in this state:\n\n. the index file and working tree is somewhere between your\n  \"maint\" and my \"master\".  \"somewhere between\" is because the\n  merge obviously failed.\n\n. the \"maint\" head has not moved.  Your .git/HEAD points at the\n  \"maint\" branch.\n\n. the \"origin\" head points at my latest \"master\" head.\n\nIf you keep a copy of my \"master\" plus zero or more of your own\ndevelopment in your \"master\" branch, and what you wanted to do\nwas to build my \"master\" plus those developments of your own,\nthen:\n\n\t$ git checkout -f master\n        $ git pull . origin\n\nIf your \"master\" is just a vanilla copy of my \"master\", then\nthis pull would result in a fast forward, and \"master\" and\n\"origin\" will point at the same commit after this pull\noperation.  Otherwise, you would merge your changes and my\n\"master\" updates into your \"master\" branch.\n\nIf what you wanted to do was to build my \"master\" vanilla, then:\n\n\t$ git checkout -f origin\n\nbecause your remotes/origin says \"origin\" is meant to be a\nstraight copy of my \"master\".\n\nA good habit to get into is, before pulling, make sure:\n\n. your index matches your HEAD.\n\n. the local modification (i.e. what git-diff-files would report)\n  is something you do not mind losing.\n\n. you are on the right branch you want to pull into (check with\n  \"git branch\").\n"},{"id":"11066","messageId":"Pine.LNX.4.64.0511031151070.25300@iabervon.org","threadId":"2333","inReplyTo":"7v4q6uhx0a.fsf@assigned-by-dhcp.cox.net","subject":"Re: Now What?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-11-03T17:05:42Z","receivedAt":"2005-11-03T17:05:42Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 3 Nov 2005, Junio C Hamano wrote:\n\n> \"Peter Eriksen\" <s022018@student.dtu.dk> writes:\n> \n> > Here's one I've done too many times:\n> >\n> > ~/git/git-core]cat .git/remotes/origin\n> > URL: git://git.kernel.org/pub/scm/git/git.git\n> > Pull: master:origin\n> >\n> > ~/git/git-core]git-checkout maint\n> > ~/git/git-core]git pull\n> \n> You are merging my master into your \"maint\", probably a copy of\n> my (previous) maint.\n\nI think the situation is that he really wanted to update master, but \nforgot that he was on the maint branch. So now he's in a merge of things \nhe didn't actually want to merge and wants to get back to not having junk \nall over the place (some files that need to be merged, some files that \nhave been merged, new files, removed files, etc).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"11067","messageId":"Pine.LNX.4.64.0511030921111.27915@g5.osdl.org","threadId":"2333","inReplyTo":"20051103083840.GA28300@ebar091.ebar.dtu.dk","subject":"Re: Now What?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-03T17:25:37Z","receivedAt":"2005-11-03T17:25:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 3 Nov 2005, Peter Eriksen wrote:\n> \n> Here's one I've done too many times:\n> \n> ~/git/git-core]cat .git/remotes/origin\n> URL: git://git.kernel.org/pub/scm/git/git.git\n> Pull: master:origin\n> \n> ~/git/git-core]git-checkout maint\n> ~/git/git-core]git pull\n> Unpacking 222 objects\n>  100% (222/222) done\n> * committish: 9534f40bc42dd826cc26c8c8c84f6a8a5fc569f6\n>   branch 'master' of git://git.kernel.org/pub/scm/git/git\n> * refs/heads/origin: storing branch 'master' of\n> * git://git.kernel.org/pub/scm/git/git\n> Trying really trivial in-index merge...\n> fatal: Merge requires file-level merging\n> Nope.\n> Trying simple merge.\n> Simple merge failed, trying Automatic merge.\n> Auto-merging Documentation/tutorial.txt.\n> Auto-merging Makefile.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in Makefile.\n> Auto-merging apply.c.\n> Auto-merging cache.h.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in cache.h.\n> Auto-merging clone-pack.c.\n> Auto-merging connect.c.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in connect.c.\n> Auto-merging daemon.c.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in daemon.c.\n> Auto-merging debian/changelog.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in debian/changelog.\n> Auto-merging fetch-pack.c.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in fetch-pack.c.\n> Auto-merging git-branch.sh.\n> Auto-merging git-checkout.sh.\n> Auto-merging git-clone.sh.\n> Auto-merging git-cvsimport.perl.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in git-cvsimport.perl.\n> Auto-merging git-fetch.sh.\n> Auto-merging git-parse-remote.sh.\n> Auto-merging git-tag.sh.\n> Auto-merging quote.c.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in quote.c.\n> Auto-merging quote.h.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in quote.h.\n> Auto-merging refs.c.\n> Auto-merging rev-list.c.\n> Auto-merging send-pack.c.\n> Auto-merging sha1_name.c.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in sha1_name.c.\n> Auto-merging upload-pack.c.\n> merge: warning: conflicts during merge\n> ERROR: Merge conflict in upload-pack.c.\n> fatal: merge program failed\n> Automatic merge failed; fix up by hand\n> \n> Indeed, what now?\n\nYou can do two things:\n\n a) decide not to merge at all:\n\n\tgit reset --hard\n\n    and you're done. This is what you want to do when you just pulled the \n    wrong branch, for example.\n\nIF you pulled the right branch, and you knew you had other changes through \nother pulls or because you just had done your own development, you want to \nlook at:\n\n b) Try to resolve the merge. Do a \"git diff\" and look what was unresolved \n    (by looking for those bog-standard resolve conflict markers like \n    \"<<<<< old ===== new >>>>>\".\n\n    Edit the conflicts by hand to what you want them to be, and do\n\n\tgit commit --all\n\n    to commit your manual merge.\n\nNote that if you start doing (b) and you decide it's too much for you, you \ncan always go back to (a) in the end and ask for help from the people \ninvolved.\n\n\t\t\tLinus\n"},{"id":"11068","messageId":"Pine.LNX.4.64.0511030926020.27915@g5.osdl.org","threadId":"2333","inReplyTo":"Pine.LNX.4.64.0511031151070.25300@iabervon.org","subject":"Re: Now What?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-03T17:27:05Z","receivedAt":"2005-11-03T17:27:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 3 Nov 2005, Daniel Barkalow wrote:\n> \n> I think the situation is that he really wanted to update master, but \n> forgot that he was on the maint branch. So now he's in a merge of things \n> he didn't actually want to merge and wants to get back to not having junk \n> all over the place (some files that need to be merged, some files that \n> have been merged, new files, removed files, etc).\n\nAnd that's exactly what \"git reset --hard\" is there for. It will reset to \nthe old head of the branch you are on (ie HEAD), and get rid of everything \nthat was done to the tree.\n\n\t\tLinus\n"},{"id":"11069","messageId":"20051103173012.GA21428@bohr.gbar.dtu.dk","threadId":"2333","inReplyTo":"Pine.LNX.4.64.0511031151070.25300@iabervon.org","subject":"Re: Now What?","fromName":"Peter Eriksen","fromEmail":"s022018@student.dtu.dk","sentAt":"2005-11-03T17:30:13Z","receivedAt":"2005-11-03T17:30:13Z","isPatch":false,"sender":{"key":"s022018@student.dtu.dk","avatar":null},"body":"On Thu, Nov 03, 2005 at 12:05:42PM -0500, Daniel Barkalow wrote:\n> On Thu, 3 Nov 2005, Junio C Hamano wrote:\n> \n> > \"Peter Eriksen\" <s022018@student.dtu.dk> writes:\n> > \n> > > Here's one I've done too many times:\n> > >\n> > > ~/git/git-core]cat .git/remotes/origin\n> > > URL: git://git.kernel.org/pub/scm/git/git.git\n> > > Pull: master:origin\n> > >\n> > > ~/git/git-core]git-checkout maint\n> > > ~/git/git-core]git pull\n> > \n> > You are merging my master into your \"maint\", probably a copy of\n> > my (previous) maint.\n> \n> I think the situation is that he really wanted to update master, but \n> forgot that he was on the maint branch. So now he's in a merge of things \n> he didn't actually want to merge and wants to get back to not having junk \n> all over the place (some files that need to be merged, some files that \n> have been merged, new files, removed files, etc).\n\nI really should have stated that from the beginning.  Yes, I forgot, I\nhad checked out some other branch and thought (the first I times assumed)\nthat it would merge into master.  So it's really just an accident,\nwhich I would think, is not that uncommon for newcommers.\n\nPeter\n"},{"id":"11072","messageId":"7vu0eth90o.fsf@assigned-by-dhcp.cox.net","threadId":"2333","inReplyTo":"Pine.LNX.4.64.0511030926020.27915@g5.osdl.org","subject":"Re: Now What?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-03T18:38:15Z","receivedAt":"2005-11-03T18:38:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> And that's exactly what \"git reset --hard\" is there for. It will reset to \n> the old head of the branch you are on (ie HEAD), and get rid of everything \n> that was done to the tree.\n\nOK, then let's rewrite the procedure using 'reset --hard'.  Then\nwe do not have to use 'checkout -f' afterwards.  The advantage\nof this approach is that 'reset --hard' would remove the new\nfiles the failed merge might have left in your working tree,\nwhile using 'checkout -f' would.\n\nWhat now?  Depends on what you wanted to do.  If what you wanted\nto do was to merge my \"master\" to your \"maint\", then you would\nresolve the conflicts by hand, but probably that was not what\nyou wanted to do.\n\nAfter that pull, your repository is in this state:\n\n. the index file and working tree is somewhere between your\n  \"maint\" and my \"master\".  \"somewhere between\" is because the\n  merge obviously failed.\n\n. the \"maint\" head has not moved.  Your .git/HEAD points at the\n  \"maint\" branch.\n\n. the \"origin\" head points at my latest \"master\" head.\n\nFirst thing is to bring your tree to a known state, to make\nrecovery easier.\n\n\t$ git reset --hard\n\nwould match your working tree to your .git/HEAD, i.e. your\n\"maint\".\n\nIf you keep a copy of my \"master\" plus zero or more of your own\ndevelopment in your \"master\" branch, and what you wanted to do\nwas to build my \"master\" plus those developments of your own,\nthen:\n\n\t$ git checkout master\n        $ git pull . origin\n\nIf your \"master\" is just a vanilla copy of my \"master\", then\nthis pull would result in a fast forward, and \"master\" and\n\"origin\" will point at the same commit after this pull\noperation.  Otherwise, you would merge your changes and my\n\"master\" updates into your \"master\" branch.\n\nIf what you wanted to do was to build my \"master\" vanilla, then:\n\n\t$ git checkout origin\n\nbecause your remotes/origin says \"origin\" is meant to be a\nstraight copy of my \"master\".\n\nA good habit to get into is, before pulling, make sure:\n\n. your index matches your HEAD.\n\n. the local modification (i.e. what git-diff-files would report)\n  is something you do not mind losing.\n\n. you are on the right branch you want to pull into (check with\n  \"git branch\").\n"},{"id":"11074","messageId":"1131043869.10979.17.camel@cashmere.sps.mot.com","threadId":"2333","inReplyTo":"20051103014307.GA1988@pe.Belkin","subject":"Re: Now What?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-11-03T18:51:10Z","receivedAt":"2005-11-03T18:51:10Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Wed, 2005-11-02 at 19:43, Chris Shoemaker wrote:\n\n> In general, for each common operation, it'd be nice to explain how to\n> \"undo\". \n\nSo, I've take a stab at the \"Reverse a Commit\" process.\nI _think_ this just about covers all the usual cases\nand encompasses much of the lore already sent to the list.\n\nI've punted (so far) on the details of the case where\nyou want to reverse a buried or copied commit.  I've\nread the howto/revert-branch-rebase.txt from Junio,\nbut I'm not satisfied with it.  While his write up\nthere is very expository and comprehensive, I think it\nis overkill for a \"simple recipe paragraph\".  Also,\nI was annoyed that \"git revert -n commit-name\" created\nconflicts and the reversal and merges didn't happen\nfor me cleanly even though they did for Junio.  I suck.\nSo either I don't get it, or it isn't working quite\nright these days.  Not sure.  Advice sought.\n\nHere's the gunk I have so far.  Does this need to be\nsimplified?  Style OK?  Send us more of same!  God help\nus all, more ASCII art!?\n\nYou know,\njdl\n\n\n\n\n\nReversing Commits\n-----------------\nWhile a goal of a revision control system is to record\nchanges and log them via commits, it is sometimes necessary\nto reverse a bogus or unwanted commit.\n\nMaking a commit in git is a reversible operation.  In order\nto realize the reversal, either the index needs to be\nreverted to its prior state, or the contents of the files\nneeds to be reverted and the index updated appropriately.\n\n\nHere is a rough flow chart to help you.  Discussion of\nthe individual cases, along with example commands, follows.\n\n\n+----------------------+\n| Oops!  I didn't mean |\n| to make that commit! |\n+----------------------+\n            |\n            |\n            |\n            V\n            ^\n          /   \\\n        / Does  \\\n      /  anyone   \\       \"Live with it\"\n     < else have a > -----------------+\n      \\  copy of  /  Yes              |\n        \\ commit/                     |\n          \\ ? /                       |\n            V                         |\n            | No                      |\n            |                         |\n            |                         |\n            V                         |\n            ^                         |\n          /   \\                       |\n        /  Is   \\                     V\n      /  commit   \\  No            +--------------------+\n     <  at top of  > ------------> | Generate and apply |\n      \\    HEAD   /     Ponder     | a reverse patch or |\n        \\   ?   /    Using StGit   | use git-revert     |\n          \\   /                    +--------------------+\n            V\n            | Yes\n            |\n            |\n            V\n            ^\n          /   \\\n        /  Are  \\\n      /   there   \\  No            +------------------------+\n     <  local dir  > ------------> | # Blow it all away     | \n      \\    mods   /                | git reset --hard HEAD^ | \n        \\   ?   /                  +------------------------+\n          \\   /                                |\n            V                                  |\n                                               |\n            | Yes                              |\n            |                                  |\n            |                                  |\n            V                                  |\n+----------------------------+                 V\n| # I want to recommit it    |     +----------------------+\n| git reset --soft HEAD^     |     | # Maybe cleanup some |  \n|                            | --> | git prune            |\n| # edit/fixup files by hand |     +----------------------+\n| # maybe git-add new files  |\n|                            |\n| git commit -a -c ORIG_HEAD |\n+----------------------------+\n\nFirst, answer this question:  Is it possible that someone\nelse has a copy of this repository with the faulty commit?\nIf so, or if the bogus commit is not the most recent commit\non the head, it is very likely the correct course of action\nis to simply make a new commit that reverses the prior, bogus\ncommit.\n\nIf there is no other copy of the repository with the bad\ncommit, then fairly simple steps can be taken to reverse\nor remove the bogus commit, but it depends on the state\nof your working directory and your intent.\n\n\nReverse a buried or copied commit\n---------------------------------\n\nFIXME: While the \"git diff | apply\" works cleanly,\n       the \"git revert\" didn't.  Ponder.\n\n    Use git show-branch to determine the patch name you\n    would like to revert.\n\n        # \"c\" is some commit name, c^ its parent\n\t% git diff c c^ | git apply\n\t% git commit -m \"Reverting commit....\"\n\n    Versus:\n\n\t% git revert -n c\n\n\n[FIXME: Reference howto/revert-branch-rebase.txt]\n\nIf you find yourself doing this sort of apply-then-revert\noperation frequently, you might want to consider the\nStGit tool [FIXME: Reference StGit].\n\n\n\nI didn't mean to do that commit! (And I want to blow it away!)\n-------------------------------------------------------------\nIf no other repository or copy of the bogus commit exists,\nyou can easily remove the immediately prior commit on a\nhead by simply reverting the index to its prior state.\n\nFirst, make sure that your working tree matches the\nlatest commit you are about to undo:\n\n\t# Should be no diffs here\n\t% git diff HEAD\n\n\t# Should be the bogus commit, forward:\n\t% git diff HEAD^\n\n\t# Should be the bogus commit, reverse:\n\t% git diff HEAD HEAD^\n\nIf that all looks fine, revert the index:\n\n\t# Revert the index to its prior (pre-commit) state\n\t% git reset --hard HEAD^\n\nBe sure you have no other modified files in your working\ndirectory as they will be overwritten by this command.\nEntirely new files that are not mentioned in the index will\nbe left untouched. However, files that are tracked in the\nindex will be reverted to their HEAD^ state.\n\n\n\nI didn't mean to do that commit! (And I want to recommit it.)\n-------------------------------------------------------------\n\nAfter making a commit and finding a mistake either in the\nchecked-in files or commit log message), you can fix it up\nby doing this:\n\n\t# Revert the index to its prior (pre-commit) state\n\t% git reset --soft HEAD^\n\n\t# Fix the checked-in files using your favorite editor\n\t# Maybe do git-add file(s) that was forgotten, etc.\n\n        % git commit -a -c ORIG_HEAD\n\nThe --soft reset leaves the working tree files intact\nand just rewinds the .git/HEAD to whatever commit you specify.\nHere, the immediately prior index state, HEAD^.  As a side\neffect it stores the original .git/HEAD in .git/ORIG_HEAD.\n\nThe -a flag to git-commit asks for all paths in the index\nto be updated.  The lowercase -c flag to git-commit requests\nan opportunity to re-edit the prior commit log message.\n\n\nCleaning Up After A Reverted Commit\n-----------------------------------\nIf you have reverted a commit using either \"git reset --hard\"\nor \"git reset --soft\", you will very likely have created\nat least one dangling commit and possibly some dangling blobs\nas well.  If you are certain you no longer need these objects,\nyou can check for fuzz and prune them:\n\n\t# Fuzz check\n\t% git fsck-objects\n\n\t# Maybe inspect the danglers using git-cat-file\n\n\t# Remove the danglers, they aren't needed\n\t$ git prune\n"},{"id":"11086","messageId":"7vll05e9j3.fsf@assigned-by-dhcp.cox.net","threadId":"2333","inReplyTo":"E1EXTw5-00063o-Gt@jdl.com","subject":"Re: Now What?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-03T20:55:28Z","receivedAt":"2005-11-03T20:55:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\n> Finally, a procedure or style question.  Should this\n> write-up be in the form of a structured FAQ?  A stand-alone\n> expository document?\n\nEarlier I suggested bunch of unconnected Documentation/howto\npages, but I'd like to take it back at least partially.  I have\ntwo alternatives; I do not know which one I prefer more...\n\nA table-of-contents (FAQ-list) with task-oriented categorization\nwould help guide the users facing \"Now What?\" situation.  It\nmight start like this:\n\n\tIt broke after you tried to ...\n\n\t* pull from remote\n\t  breakage #1 --> see this...\n\t  breakage #2 --> see that...\n\t  ...\n\n        * checkout a branch\n\t  breakage #1 --> see this...\n\t  breakage #2 --> see that...\n\t  ...\n\nand each breakage and solution would be a separate document.\n\nIf we go with this separate FAQ-list approach, I'd love to keep\nthe result under Documentation/ hierarchy we ship as part of the\nsource, but I suspect that building-up this kind of thing might\nbe better suited to Wiki.  I wonder if there is a Wiki whose\ndocument storage format is in asciidoc, and uses git as its\nrevision control backend.  Then we could let people update Wiki,\nand occasionally merge from there.  We also should be able to\npush things back to Wiki, essentially treating Wiki as one of\nthe repositories from the git side.  Hmm...\n\n\nThe other alternative is to add \"NOW WHAT\" section to each man\npage.  The idea is that \"if the last command you ran was this\ncommand and if it did not do what you wanted it to do, here are\nits common failure modes and how you would recover from them\".\nSo the materials we covered during the failed pull/merge\ndiscussion would go to \"NOW WHAT\" section of git-pull(1), with\nperhaps git-merge(1) saying \"See also\".\n\nWe would want \"EXAMPLES\" section for all the major commands as\nsuggested by Linus anyway, and going this way we _may_ be able\nto get away without coming up with the higher level problem\ncategorization; the user would at least know what the last\ncommand he tried to use was already.\n"},{"id":"11092","messageId":"7vll05bd1w.fsf@assigned-by-dhcp.cox.net","threadId":"2333","inReplyTo":"Pine.LNX.4.64.0511031151070.25300@iabervon.org","subject":"Re: Now What?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-03T22:07:39Z","receivedAt":"2005-11-03T22:07:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> On Thu, 3 Nov 2005, Junio C Hamano wrote:\n>\n>> \"Peter Eriksen\" <s022018@student.dtu.dk> writes:\n>> \n>> > ~/git/git-core]cat .git/remotes/origin\n>> > URL: git://git.kernel.org/pub/scm/git/git.git\n>> > Pull: master:origin\n>> >\n>> > ~/git/git-core]git-checkout maint\n>> > ~/git/git-core]git pull\n>> \n>> You are merging my master into your \"maint\", probably a copy of\n>> my (previous) maint.\n>\n> I think the situation is that he really wanted to update master, but \n> forgot that he was on the maint branch.\n\nI wonder if it would make sense to have something in .git/remotes/\nfile that says \"run merge only when I am on frotz branch\", like\nthis:\n\n        ~/git/git-core]cat .git/remotes/origin\n        URL: git://git.kernel.org/pub/scm/git/git.git\n        Pull: master:origin\n\tFetch-Only-Unless: master\n\n        ~/git/git-core]git-checkout maint\n\t~/git/git-core]git pull\n\twarning: not merging because you are not on 'master' branch.\n\nThis would make the above \"git pull\" behave identical to \"git\nfetch\", and the user can then do:\n\n\t$ git checkout master\n        $ git pull . origin\n\nUseful?  Useless?\n"},{"id":"11093","messageId":"200511032317.15393.Josef.Weidendorfer@gmx.de","threadId":"2333","inReplyTo":"7vll05e9j3.fsf@assigned-by-dhcp.cox.net","subject":"Re: Now What?","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-03T22:17:15Z","receivedAt":"2005-11-03T22:17:15Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 03 November 2005 21:55, Junio C Hamano wrote:\n> be better suited to Wiki.  I wonder if there is a Wiki whose\n> document storage format is in asciidoc, and uses git as its\n> revision control backend.\n\nI wonder if Git is the best SCM for a Wiki, as you want per-file\nrevisions in a Wiki: when reverting a page to a previous version,\nthis should not modify other pages.\nSo you have an index and a HEAD for every file.\nTo snapshot a state of such a multihead repository, it would be\nnice to have tag objects able to hold multiple SHAs of commits.\nOr can we use tree objects for this?\n\nJosef\n"},{"id":"11095","messageId":"200511032333.13823.Josef.Weidendorfer@gmx.de","threadId":"2333","inReplyTo":"7vll05bd1w.fsf@assigned-by-dhcp.cox.net","subject":"Re: Now What?","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-03T22:33:13Z","receivedAt":"2005-11-03T22:33:13Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 03 November 2005 23:07, Junio C Hamano wrote:\n> I wonder if it would make sense to have something in .git/remotes/\n> file that says \"run merge only when I am on frotz branch\", like\n> this:\n> \n>         ~/git/git-core]cat .git/remotes/origin\n>         URL: git://git.kernel.org/pub/scm/git/git.git\n>         Pull: master:origin\n> \tFetch-Only-Unless: master\n> \n>         ~/git/git-core]git-checkout maint\n> \t~/git/git-core]git pull\n> \twarning: not merging because you are not on 'master' branch.\n\nThis is quite limiting, if you keep multiple branches from origin in your\nrepository.\nIt would be better to be able to specify per-branch Pull lines. I.e. the\ndefault pull action depends on the branch you are on.\n\n        URL: git://git.kernel.org/pub/scm/git/git.git\n        Pull(master): master:origin\n\n        ~/git/git-core]git-checkout maint\n \t~/git/git-core]git pull\n \twarning: no default pull action for branch 'maint' specified\n\nSyntax arguable.\n\nJosef\n"},{"id":"11098","messageId":"7vwtjp9wgc.fsf@assigned-by-dhcp.cox.net","threadId":"2333","inReplyTo":"200511032317.15393.Josef.Weidendorfer@gmx.de","subject":"Re: Now What?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-03T22:51:31Z","receivedAt":"2005-11-03T22:51:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n\n> On Thursday 03 November 2005 21:55, Junio C Hamano wrote:\n>> be better suited to Wiki.  I wonder if there is a Wiki whose\n>> document storage format is in asciidoc, and uses git as its\n>> revision control backend.\n>\n> I wonder if Git is the best SCM for a Wiki, as you want per-file\n> revisions in a Wiki: when reverting a page to a previous version,\n> this should not modify other pages.\n\nSorry, I do not see why per-file revisioning is mandatory.\nWouldn't revert or edit of a single page be just a new commit of\nthe new whole tree with just a single path changed?\n\nI understand that whole tree history may not be much useful in\nWiki environment, but I do not see why it would hurt to have a\nwhole tree history (except perhaps the commit log may not be\nvery useful).\n\nIn fact, wouldn't svnwiki already does the same thing?\n"},{"id":"11101","messageId":"200511040026.16879.Josef.Weidendorfer@gmx.de","threadId":"2333","inReplyTo":"7vwtjp9wgc.fsf@assigned-by-dhcp.cox.net","subject":"Re: Now What?","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-03T23:26:16Z","receivedAt":"2005-11-03T23:26:16Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 03 November 2005 23:51, Junio C Hamano wrote:\n> > I wonder if Git is the best SCM for a Wiki, as you want per-file\n> > revisions in a Wiki: when reverting a page to a previous version,\n> > this should not modify other pages.\n> \n> Sorry, I do not see why per-file revisioning is mandatory.\n> Wouldn't revert or edit of a single page be just a new commit of\n> the new whole tree with just a single path changed?\n\nYou are right.\nObviously I should get some sleep ;-)\n\nAs you said, by adding a new commit for every page revert, you get\na really messy history. If there is vandalism in a Wiki, wouldn't\nit be better to be able to get rid of spam versions of one Wiki page?\n\n> In fact, wouldn't svnwiki already does the same thing?\n\nProbably. I don't know it.\n\nJosef\n"},{"id":"11136","messageId":"Pine.LNX.4.64.0511041158350.25300@iabervon.org","threadId":"2333","inReplyTo":"7vll05bd1w.fsf@assigned-by-dhcp.cox.net","subject":"Re: Now What?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-11-04T17:06:28Z","receivedAt":"2005-11-04T17:06:28Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 3 Nov 2005, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > On Thu, 3 Nov 2005, Junio C Hamano wrote:\n> >\n> >> \"Peter Eriksen\" <s022018@student.dtu.dk> writes:\n> >> \n> >> > ~/git/git-core]cat .git/remotes/origin\n> >> > URL: git://git.kernel.org/pub/scm/git/git.git\n> >> > Pull: master:origin\n> >> >\n> >> > ~/git/git-core]git-checkout maint\n> >> > ~/git/git-core]git pull\n> >> \n> >> You are merging my master into your \"maint\", probably a copy of\n> >> my (previous) maint.\n> >\n> > I think the situation is that he really wanted to update master, but \n> > forgot that he was on the maint branch.\n> \n> I wonder if it would make sense to have something in .git/remotes/\n> file that says \"run merge only when I am on frotz branch\", like\n> this:\n> \n>         ~/git/git-core]cat .git/remotes/origin\n>         URL: git://git.kernel.org/pub/scm/git/git.git\n>         Pull: master:origin\n> \tFetch-Only-Unless: master\n> \n>         ~/git/git-core]git-checkout maint\n> \t~/git/git-core]git pull\n> \twarning: not merging because you are not on 'master' branch.\n> \n> This would make the above \"git pull\" behave identical to \"git\n> fetch\", and the user can then do:\n> \n> \t$ git checkout master\n>         $ git pull . origin\n> \n> Useful?  Useless?\n\nPeople probably want to merge master into their personal work branches, \nthough; I think it would be better to have it list branches into which it \nshouldn't be merged. I think the pair of \"maint\" and \"master\" are special, \nin that they get different fixes for the same problems, and so they'll \nmerge badly or to a wrong result.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"11218","messageId":"7vr79twm7l.fsf@assigned-by-dhcp.cox.net","threadId":"2333","inReplyTo":"1131043869.10979.17.camel@cashmere.sps.mot.com","subject":"Re: Now What?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-06T20:33:18Z","receivedAt":"2005-11-06T20:33:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\n> On Wed, 2005-11-02 at 19:43, Chris Shoemaker wrote:\n>\n> ....  Also,\n> I was annoyed that \"git revert -n commit-name\" created\n> conflicts and the reversal and merges didn't happen\n> for me cleanly even though they did for Junio.\n>\n> So either I don't get it, or it isn't working quite\n> right these days.  Not sure.  Advice sought.\n\nIt's been a while since I used git-revert the last time.  I\nshould find time to run the examples myself.\n\n> Reversing Commits\n> -----------------\n> While a goal of a revision control system is to record\n> ...\n\nThe flow-chart based recipe is wonderful.\n"}]}