{"thread":{"id":"13891","subject":"Help rescuing a repository","startedAt":"2008-06-11T01:19:43Z","lastAt":"2008-06-11T07:46:49Z","messageCount":4,"participants":["Luke Lu","Linus Torvalds","Pierre Habouzit"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"79412","messageId":"C061111B-1696-4545-A3F0-D0B8B961A352@vicaya.com","threadId":"13891","inReplyTo":null,"subject":"Help rescuing a repository","fromName":"Luke Lu","fromEmail":"git@vicaya.com","sentAt":"2008-06-11T01:19:43Z","receivedAt":"2008-06-11T01:19:43Z","isPatch":false,"sender":{"key":"git@vicaya.com","avatar":null},"body":"I was doing some git rebase -i in a topic branch (topic/ser) to squash  \nand reorder some commits. There were some conflicts. I fixed the  \nconflicts and typed git rebase --continue. The cycle continued a few  \ntimes and then this happened:\n\n  13 files changed, 68 insertions(+), 41 deletions(-)\nerror: Ref refs/heads/topic/ser is at  \n5cfb6b694f2d5a1ff429fe86f6c5ecafed159e47 but expected  \na10a7127be3441c732cab5baa2dd8684591f91f7\nfatal: Cannot lock the ref 'refs/heads/topic/ser'.\n\n$ git status\n# Not currently on any branch.\nnothing to commit (working directory clean)\n\n$ git fsck\ndangling blob 8861482c7e1731be2436f75ae6276d0f9c4833e0\ndangling blob 94c1b94b5146b58cda4ee50854241b192f701bea\ndangling blob 01a2371e749ab7e14707cfb4d3846035fcaee728\ndangling blob 4ca2b920849a1517a46279c4b56896fd79625a6c\ndangling blob 56e32abf19627dcf79ee123bae9ddb08423bc5ba\ndangling blob 73832cd404915d7bc5e0aac1e87fa3bb64293531\ndangling tree 73c34a56d1da91d4ea606055d558ef290949fb70\ndangling blob b5c3dfefd345e8296e56518b7e537d9e20814288\ndangling blob c743999c4762380d3d318ae7b80bba32d4bc4f53\ndangling tree 1184c889e044163dd857f3858c09970080720993\ndangling blob eca57f10d1dc19dc4bb3dba2c08e393c1e31832b\ndangling blob f5a5b7e5e922412ebeabdbc52ecc3354298e3690\ndangling blob 47064db7a58b95d02885e5c3004b7920a0dc534f\ndangling blob 4966a6f65c912418b33b13fe6f10fb368c2545cf\ndangling commit 75c6f9bb9d093390d260819f80cd94fc20849d30\ndangling blob bd4752468dbb11274285184cb0c602a2cd259eb5\ndangling blob c8074b20ded0a36ff07df5595116442af5515498\ndangling tree 0848c028fc28008de1a845c9524e3ab12df9832b\ndangling blob 7ec9928b3c0db7ec737fa70b4bb9615b068ee990\ndangling blob b44967adc33ec1ddcba49f75cd55127facbb7a00\ndangling blob 23ca6b90505dae2607af6415e3ccc038daf0109d\ndangling blob b58aac43a313abf6ac21754ec258caeb388a16f6\ndangling blob eeebecd8db7d263f77e132b2e82ac4864775b61c\ndangling blob 3e0c62d3e778bef1a0f17379ba2a3731da629fce\ndangling blob 20cd6eab485de1b0d412cf16e41e88b92ab7e977\ndangling blob 8b6d1ba9efb6de596a77aa4be6a36db3d2c6687c\ndangling blob b58de59a60c002f99c6ef2463f1678106f07da7d\ndangling blob 2fae8d768ac0ae872f513566334d9b4134cf1e28\ndangling blob 33ee2202ded44151efb066bc567845b259ce7217\ndangling blob afae3fef0b92b14acf7fb1c3e511561111986de5\ndangling blob 3f6fd047ac02f1ec7694fd906c762320ed148532\ndangling blob 85afb26ca1d651e1745537c60fda5a1807048cb4\ndangling blob a30f3e844d6eba2f23ed91470962f12ffebaf0cf\ndangling blob bdafe70378182035702a41a7f8854e9f3eaef7dd\ndangling blob e96fd7d00b6c05a48477f64ce0085f1fa40207a1\ndangling blob 2390ce4ff58008ac1fd3b54dae31116ff4dbbbae\ndangling blob 4ab0f1a55f987f1c2e06406199b96ce2e7388bcb\ndangling blob 75b0f4cc59aa4a3ae9ac1fa01fbb6383d6584aac\ndangling blob 9b7035d40c61259563470a2ea42c2943aec443d0\ndangling blob 1752370b44a133f1519ffef5452f772cef99c93f\ndangling blob 10b316e7f25212e66e1213dc1303b03339bf6648\ndangling blob 883397ee9b21724e03547e7ca71c60e87cd7bbfa\ndangling tree 8f135a32c77825713ec70b7367d1134b9dc15006\ndangling tree 91f394d3e2566f703434ba3a6b3021496d1167ef\ndangling blob 2374b17b997a232835ad817c1173a5bd1e34d30b\ndangling blob 8894bb0e8dad66c3cf57350e36252a2f1746a6fb\ndangling blob 20b522551d824bfd83685f391d490308dae7c3e1\ndangling blob 8cb6086ec13a97a88b9530983f4b4dd77905615f\ndangling blob a997eaf05db866b0108e9c754129418237384aed\ndangling tree 6118e30cbefd3fe26c51fce8595674a55ff24279\ndangling blob 88d9b06bc81abd155604c8ef6b595042bc955d45\ndangling blob dfd925e457eb9295587029dca7ce1060f7cc030c\ndangling blob c3fbac839f7e35c208110cfab9c0d95eae3f488b\ndangling blob 34bce1a591d9bf67bab966a9a9cfeff5e3723d11\ndangling blob 9f5c4d0b8bd5e169d1c36658dfd8b1d508641093\ndangling blob 1fdda77640dd0d0bf48fe4ee88ab823cb004d8fa\ndangling blob 495d6c267d62f82a5a4f0d6c75d111cebcdb3f29\ndangling blob c87df955d86c2c13ca45b90ac9a598ba901ba06e\ndangling blob 20dee3523801fa85182d2159d4f6ad2fe5c56bad\ndangling blob 3f1ea7888bf98019df10c4e5aa6b22cd65daf8d1\ndangling blob 8d5ef43998cb64575c4902ac7855d394b5f9d326\ndangling blob 121f865528655c03cfbb10d0c29dda678666eb8e\ndangling blob badfc40fabb32650ccbb33456766e9d58588f8ed\ndangling commit d2bf234e4b0735695a59836f04b4f1558ebacfdc\ndangling blob f3df2aebbbd0b00dc8210b6c51806d7f4fd409ef\n\nI've used git rebase -i before without any problem. The only  \ndifference this time is that there are more commits (50+) and more  \nfiles (hundreds) and changes (thousands) involved due to some global  \nfind & replace. I *might* have committed something in the same branch,  \nwhile the git rebase -i editor window is open (there are a lot of  \ncommits to reorder and squash, so I used another window to look at the  \ncommits I'm not sure about. I might have done a quick fix (likely  \nwhitespace errors :) and committed)\n\n$ git --version\ngit version 1.5.5.1\n\nI have the gut feeling that it might be fixable by some magical  \nincantation to connect the refs to my branch. But I don't know git  \ninternal very well. I need your help. My work obviously depend upon it.\n\nThanks in advance!\n"},{"id":"79421","messageId":"alpine.LFD.1.10.0806101848320.3101@woody.linux-foundation.org","threadId":"13891","inReplyTo":"C061111B-1696-4545-A3F0-D0B8B961A352@vicaya.com","subject":"Re: Help rescuing a repository","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-06-11T02:08:31Z","receivedAt":"2008-06-11T02:08:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 10 Jun 2008, Luke Lu wrote:\n>\n> I was doing some git rebase -i in a topic branch (topic/ser) to squash and\n> reorder some commits. There were some conflicts. I fixed the conflicts and\n> typed git rebase --continue. The cycle continued a few times and then this\n> happened:\n> \n> 13 files changed, 68 insertions(+), 41 deletions(-)\n> error: Ref refs/heads/topic/ser is at 5cfb6b694f2d5a1ff429fe86f6c5ecafed159e47\n> but expected a10a7127be3441c732cab5baa2dd8684591f91f7\n> fatal: Cannot lock the ref 'refs/heads/topic/ser'.\n\nOk, you seem to have committed something in another session (other window \nor something) at the same time as doing that git rebase series. As a \nresult, the rebasing commit was unhappy, because you basically ripped the \nrug out from under it by changing the branch it was working on.\n\n> $ git status\n> # Not currently on any branch.\n> nothing to commit (working directory clean)\n\nDon't worry. Nothing has gone away, although you may now need to *find* \nthe particular branch tip(s) that you are interested in.\n\n> I've used git rebase -i before without any problem. The only difference this\n> time is that there are more commits (50+) and more files (hundreds) and\n> changes (thousands) involved due to some global find & replace.\n\nThat shouldn't matter, except that it was obviously very likely one of the \nreasons for the conflicts too.\n\nWhat mattered is:\n\n> I *might* have committed something in the same branch, while the git \n> rebase -i editor window is open (there are a lot of commits to reorder \n> and squash, so I used another window to look at the commits I'm not sure \n> about. I might have done a quick fix (likely whitespace errors :) and \n> committed)\n\nYup, that would explain it.\n\n> I have the gut feeling that it might be fixable by some magical incantation to\n> connect the refs to my branch. But I don't know git internal very well. I need\n> your help. My work obviously depend upon it.\n\nMost likely, the only thing you actually need to do is simply\n\n\tgit rebase --abort\n\nand it will just take you back to the state you were in before the rebase, \nand now you'll have to redo it all.\n\nBUT. You can also decide that instead of doing that, you want to keep the \nwork you did do, and just try to continue. You'll just need to figure out \nwhere you are, and where the rest of the commits you want to do are.\n\nAnd those things should not be so hard to figure out, at least if you \nstill have a reasonably good idea about what the commits were that you \ncared about. You just need to find all the relevant development tips, and \nit turns out that that is actually mostly pretty easy.\n\nYou have one right there: the current disconnected HEAD you are on is one \ntip. You can save that one away by making that a real branch, so you don't \nlose it, with something like\n\n\tgit branch middle-of-rebase\n\nwhich will just take your current state, and make it the new branch \n'middle-of-rebase'.\n\nYou can also try to get a better view of where you are by doing\n\n\tgitk --all\n\nto show all the branches graphically, which is usually a great way to get \nyour bearings. Keep the gitk window open in the background as a reference.\n\nAfter that, do\n\n\tgit log -g\n\nwher the \"-g\" (or \"--walk-reflogs\" for the long version) just means that \ninstead of looking through history as a chain of commits and their \nparents, you look through not the chain of commits, but as the chain of \nreflog entries (which are basically about how the HEAD has changed due to \nthe commands you have done).\n\nIn all of that info, look for the place you want to go back to, and just \nstart all over from there. You can either re-use one of your old branches \nand just start over from some state that you want:\n\n\tgit checkout <branch>\n\tgit reset --hard <startingpoint>\n\nor you can decide that you want to start a new branch to fix up the mess \n\n\tgit checkout -b <newbranch> <startingpoint>\n\nand only when it's all fixed up and you're happy will you change any of \nyour old branches.\n\nBut it may well be that \"git rebase --abort\" and re-doing everything is\nthe least confusing option.\n\n\t\t\tLinus\n"},{"id":"79428","messageId":"025E3DB6-D0A8-497E-A5EF-9B4011FA3272@vicaya.com","threadId":"13891","inReplyTo":"alpine.LFD.1.10.0806101848320.3101@woody.linux-foundation.org","subject":"Re: Help rescuing a repository","fromName":"Luke Lu","fromEmail":"git@vicaya.com","sentAt":"2008-06-11T05:04:25Z","receivedAt":"2008-06-11T05:04:25Z","isPatch":false,"sender":{"key":"git@vicaya.com","avatar":null},"body":"On Jun 10, 2008, at 7:08 PM, Linus Torvalds wrote:\n>\n> On Tue, 10 Jun 2008, Luke Lu wrote:\n>>\n>> I was doing some git rebase -i in a topic branch (topic/ser) to  \n>> squash and\n>> reorder some commits. There were some conflicts. I fixed the  \n>> conflicts and\n>> typed git rebase --continue. The cycle continued a few times and  \n>> then this\n>> happened:\n>>\n>> 13 files changed, 68 insertions(+), 41 deletions(-)\n>> error: Ref refs/heads/topic/ser is at  \n>> 5cfb6b694f2d5a1ff429fe86f6c5ecafed159e47\n>> but expected a10a7127be3441c732cab5baa2dd8684591f91f7\n>> fatal: Cannot lock the ref 'refs/heads/topic/ser'.\n>\n> Ok, you seem to have committed something in another session (other  \n> window\n> or something) at the same time as doing that git rebase series. As a\n> result, the rebasing commit was unhappy, because you basically  \n> ripped the\n> rug out from under it by changing the branch it was working on.\n\nSo you've seen this problem before?\n\n>> I *might* have committed something in the same branch, while the git\n>> rebase -i editor window is open (there are a lot of commits to  \n>> reorder\n>> and squash, so I used another window to look at the commits I'm not  \n>> sure\n>> about. I might have done a quick fix (likely whitespace errors :) and\n>> committed)\n>\n> Yup, that would explain it.\n>\n>> I have the gut feeling that it might be fixable by some magical  \n>> incantation to\n>> connect the refs to my branch. But I don't know git internal very  \n>> well. I need\n>> your help. My work obviously depend upon it.\n>\n> Most likely, the only thing you actually need to do is simply\n>\n> \tgit rebase --abort\n>\n> and it will just take you back to the state you were in before the  \n> rebase,\n> and now you'll have to redo it all.\n\nBefore I thought of that, I just used the trusted git reflog to find  \nthe last commit I made before the rebase commits and did a git reset -- \nhard to that commit. It returned the tree to normal. Fortunately I  \nhave rerere enabled (by creating the .git/rr-cache directory, because  \nI read your and Junio's posts on kernel trap). so I don't have to do  \nmuch work to reedit the conflicts.\n\n> BUT. You can also decide that instead of doing that, you want to  \n> keep the\n> work you did do, and just try to continue. You'll just need to  \n> figure out\n> where you are, and where the rest of the commits you want to do are.\n>\n> And those things should not be so hard to figure out, at least if you\n> still have a reasonably good idea about what the commits were that you\n> cared about. You just need to find all the relevant development  \n> tips, and\n> it turns out that that is actually mostly pretty easy.\n>\n> You have one right there: the current disconnected HEAD you are on  \n> is one\n> tip. You can save that one away by making that a real branch, so you  \n> don't\n> lose it, with something like\n>\n> \tgit branch middle-of-rebase\n>\n> which will just take your current state, and make it the new branch\n> 'middle-of-rebase'.\n>\n> You can also try to get a better view of where you are by doing\n>\n> \tgitk --all\n>\n> to show all the branches graphically, which is usually a great way  \n> to get\n> your bearings. Keep the gitk window open in the background as a  \n> reference.\n>\n> After that, do\n>\n> \tgit log -g\n>\n> wher the \"-g\" (or \"--walk-reflogs\" for the long version) just means  \n> that\n> instead of looking through history as a chain of commits and their\n> parents, you look through not the chain of commits, but as the chain  \n> of\n> reflog entries (which are basically about how the HEAD has changed  \n> due to\n> the commands you have done).\n>\n> In all of that info, look for the place you want to go back to, and  \n> just\n> start all over from there. You can either re-use one of your old  \n> branches\n> and just start over from some state that you want:\n>\n> \tgit checkout <branch>\n> \tgit reset --hard <startingpoint>\n>\n> or you can decide that you want to start a new branch to fix up the  \n> mess\n>\n> \tgit checkout -b <newbranch> <startingpoint>\n>\n> and only when it's all fixed up and you're happy will you change any  \n> of\n> your old branches.\n\nI'm still not sure how to fixed it up and keep the merge results  \nthough. Just work on the tree (middle-of-rebase, which is actually the  \nend of rebase, when it blowed up) until it's good and reset --hard my  \nbranch to it?\n\n> But it may well be that \"git rebase --abort\" and re-doing everything  \n> is\n> the least confusing option.\n\n\ngit rebase --abort, I think, would actually blow away my last commit  \n(I sneaked in) though. git reset --hard to that last commit is  \nprobably the right thing to do. The least confusing option would be to  \nupdate the error message to be a bit more informative, like \"Did you  \nchange the branch while rebasing? git reset --hard to your last known  \ncommit and redo the rebase\". Yet another safeguard would be for git  \ncommit to check if there is a rebase in progress and warn or abort the  \ncommit.\n\nAnyway, thanks for the informative reply. I have more confidence in  \ngit due to this accident :)\n\n__Luke\n"},{"id":"79439","messageId":"20080611074649.GC28629@artemis.madism.org","threadId":"13891","inReplyTo":"025E3DB6-D0A8-497E-A5EF-9B4011FA3272@vicaya.com","subject":"Re: Help rescuing a repository","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-06-11T07:46:49Z","receivedAt":"2008-06-11T07:46:49Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Jun 11, 2008 at 05:04:25AM +0000, Luke Lu wrote:\n> git rebase --abort, I think, would actually blow away my last commit (I \n> sneaked in) though. git reset --hard to that last commit is probably the \n> right thing to do. The least confusing option would be to update the \n> error message to be a bit more informative, like \"Did you change the \n> branch while rebasing? git reset --hard to your last known commit and \n> redo the rebase\". Yet another safeguard would be for git commit to check \n> if there is a rebase in progress and warn or abort the commit.\n\n  OTOH the commit you did has been your HEAD for a moment, so it's\neasily cherry-pickable from your reflog. So I'd go for the git rebase\n--abort route, redo the rebase, and once done, then run git reflog and\nfind the commit that you want to get back, and cherry-pick it with its\nproper reflog name: git cherry-pick HEAD@{nnn}.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"}]}