{"thread":{"id":"27122","subject":"git leaves repo in bad state in out-of-space situation","startedAt":"2011-04-17T06:40:26Z","lastAt":"2011-04-17T19:09:18Z","messageCount":3,"participants":["Luke Hutchison","Dmitry Potapov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"166004","messageId":"BANLkTi=4EvRZK_bK=JrwiZgfaeHvNgj-dQ@mail.gmail.com","threadId":"27122","inReplyTo":null,"subject":"git leaves repo in bad state in out-of-space situation","fromName":"Luke Hutchison","fromEmail":"luke.hutch@gmail.com","sentAt":"2011-04-17T06:40:26Z","receivedAt":"2011-04-17T06:40:26Z","isPatch":false,"sender":{"key":"luke.hutch@gmail.com","avatar":null},"body":"I just did a git pull and ran out of disk space halfway through, which\nleft me with a bunch of \"Could not create file <filename>\" errors.  I\nfreed up space and tried to repeat the git pull.  Now my repo is\nb0rked:\n\n$ git pull\nUpdating eedace8..a37dbb1\nerror: Your local changes to the following files would be overwritten by merge:\n        <list of some of the pulled files>\nPlease, commit your changes or stash them before you can merge.\nerror: The following untracked working tree files would be overwritten by merge:\n        <a lot more of the pulled files>\n\nI wasn't sure how to fix this, and this was probably the wrong\nresponse, but I tried \"git add . ; git commit -a -m test ; git push\"\nand got a bunch of merge conflicts due to zero-length binary files\n(PNGs etc.).  Repeating this again I get \"up to date\" but some of my\nfiles have now been replaced in the repo with zero-length versions,\nwhich seems dangerous if I didn't notice it and just assumed that git\nhad worked its magic and fixed the situation.\n\nI know that gracefully handling out-of-diskspace situations is a pain,\nand it's hard to catch each corner case.  But it seems like git could\ndegrade a little more elegantly in this situation (e.g. files should\nnot just be created with zero length if there is no disk space left).\nThoughts?\n\nNot sure of the right way to fix my current situation, I'll probably\njust overwrite my local copy of the repo with a remote copy using scp\nand then try pushing again.\n\nI assume this mailing list is the right place to report bugs, since I\ndon't see a bug tracker?  I tried looking in the FAQ at\nhttps://git.wiki.kernel.org/index.php/GitFaq , but got:\n\nDatabase error\nA database error has occurred\nQuery: SELECT lc_value FROM `l10n_cache` WHERE lc_lang = 'en' AND\nlc_key = 'deps' LIMIT 1\nFunction: LCStore_DB::get\nError: 1146 Table 'gitwiki.l10n_cache' doesn't exist (127.0.0.1:4040)\n\nThanks,\nLuke Hutchison\n"},{"id":"166008","messageId":"BANLkTim4=eKQ2wq73Lf5zrjOND-r1n0XCw@mail.gmail.com","threadId":"27122","inReplyTo":"BANLkTi=4EvRZK_bK=JrwiZgfaeHvNgj-dQ@mail.gmail.com","subject":"Re: git leaves repo in bad state in out-of-space situation","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-04-17T13:38:20Z","receivedAt":"2011-04-17T13:38:20Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"Hi,\n\nOn Sun, Apr 17, 2011 at 10:40 AM, Luke Hutchison <luke.hutch@gmail.com> wrote:\n> I just did a git pull and ran out of disk space halfway through, which\n> left me with a bunch of \"Could not create file <filename>\" errors.  I\n> freed up space and tried to repeat the git pull.  Now my repo is\n> b0rked:\n>\n> $ git pull\n> Updating eedace8..a37dbb1\n> error: Your local changes to the following files would be overwritten by merge:\n>        <list of some of the pulled files>\n> Please, commit your changes or stash them before you can merge.\n> error: The following untracked working tree files would be overwritten by merge:\n>        <a lot more of the pulled files>\n\nThe repository is not borked, it's just your working tree is in an\ninconsistent state, but it is easy to fix:\n\ngit reset --hard HEAD\n\ni.e. to discard all changes in your working tree. BTW, it is not only\nuseful in the above situation, but when in the process of merging you\ndiscover that you've resolved some conflicts in the wrong way and want\nto re-do all merge again.\n\n> I wasn't sure how to fix this, and this was probably the wrong\n> response, but I tried \"git add . ; git commit -a -m test ; git push\"\n\nand that was a silly thing to do... In fact, committing everything\nblindly is almost always a bad idea...\n\nBTW, did you mean \"git pull\" above? Because if you did \"git push\"\nthen those bogus changes are at the server now.\n\n> and got a bunch of merge conflicts due to zero-length binary files\n> (PNGs etc.).  Repeating this again I get \"up to date\" but some of my\n> files have now been replaced in the repo with zero-length versions,\n> which seems dangerous if I didn't notice it and just assumed that git\n> had worked its magic and fixed the situation.\n\ngit does not do magic, it does exactly what you say. If you said in\nthe previous commit to change some files to have a zero length then\nyou should not be surprise that they are empty now.\n\nIt always helps to run \"gitk --all\" to see what you are doing.\n\n> I know that gracefully handling out-of-diskspace situations is a pain,\n> and it's hard to catch each corner case.  But it seems like git could\n> degrade a little more elegantly in this situation (e.g. files should\n> not just be created with zero length if there is no disk space left).\n> Thoughts?\n\nCreating or not creating files with zero length would not make any\npractical difference here (instead of having zero it would be appeared\nremoved). There are many situations when checkout (reading files to\nthe work tree may fail in the middle), for instance, the user could\npress CTRL-C, which will leave the working in an inconsistent state.\n\nSo, the general solution is only one:\n\n  git reset --hard HEAD\n\n\nDmitry\n"},{"id":"166018","messageId":"BANLkTimVBVwz7c4=U0-zHhAWztewWYs7Qw@mail.gmail.com","threadId":"27122","inReplyTo":"BANLkTim4=eKQ2wq73Lf5zrjOND-r1n0XCw@mail.gmail.com","subject":"Re: git leaves repo in bad state in out-of-space situation","fromName":"Luke Hutchison","fromEmail":"luke.hutch@gmail.com","sentAt":"2011-04-17T19:09:18Z","receivedAt":"2011-04-17T19:09:18Z","isPatch":false,"sender":{"key":"luke.hutch@gmail.com","avatar":null},"body":"Hi Dmitry,\n\nOn Sun, Apr 17, 2011 at 9:38 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:\n> The repository is not borked, it's just your working tree is in an\n> inconsistent state, but it is easy to fix:\n>\n> git reset --hard HEAD\n\nAh, sounds like my intuition that simply freeing up space and then\nre-pulling should have fixed the problem was wrong.  Your explanation\nmakes sense.\n\n> BTW, did you mean \"git pull\" above? Because if you did \"git push\"\n> then those bogus changes are at the server now.\n\nNo, I work with a centralized repository which requires push\noperations.  I know this negates the benefit of distributed SCM.\n\n> It always helps to run \"gitk --all\" to see what you are doing.\n> [...]\n> So, the general solution is only one:\n>\n>  git reset --hard HEAD\n\nThank you for your patient responses to what turned out to be a very\nbasic question!  My typical git workflow is very simple and has worked\nfine until I ran out of disk space.\n\nLuke\n"}]}