{"thread":{"id":"26289","subject":"panic recovery","startedAt":"2011-01-16T12:33:34Z","lastAt":"2011-01-17T18:42:38Z","messageCount":4,"participants":["Levend Sayar","Thomas Rast","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159546","messageId":"AANLkTikBjWU_dm1a+2AQyP-bhdO_WtYJ8OdE7Zs3E=kV@mail.gmail.com","threadId":"26289","inReplyTo":null,"subject":"panic recovery","fromName":"Levend Sayar","fromEmail":"levendsayar@gmail.com","sentAt":"2011-01-16T12:33:34Z","receivedAt":"2011-01-16T12:33:34Z","isPatch":false,"sender":{"key":"levendsayar@gmail.com","avatar":"https://gravatar.com/avatar/eee5111f431e01d6607dcdce1434e09cd262a451cf27ddab2db11ec0d7197be3?d=mp&s=160"},"body":"Hi, all.\n\nYesterday one of my colleague tried to commit her two weeks of work.\nNearly 10 source code files.\nAfter an unsuccessful am and apply commands, she tried rebase. And git\nbothered something like you have to finish your am first.\nThen I suggested to do\n\ngit am --abort\n\nAfter that, we saw that all the sources she developed for two weeks\nare gone. We really got panic.But I know that git stores everthing as\nobjects, namely commit,tree,blob and tag objects.\n\nWe sorted every file according to modification time under .git/objects\ndirectory and use \"git show\" for every single object.\nAfter a cumbersome work, we found blob objects for our source codes\nthat we lost and commit objects. Namely we rescued her work.\n\nIs there a better way to use in this kind of situations ?\n\nFor example, to list every single objects under objects directory\naccording to their types ?\nOr search a phrase in every blob obejcts to find the source code we\nare looking for ?\n\n_lvnd_\n(^_^)\n"},{"id":"159547","messageId":"201101161338.54423.trast@student.ethz.ch","threadId":"26289","inReplyTo":"AANLkTikBjWU_dm1a+2AQyP-bhdO_WtYJ8OdE7Zs3E=kV@mail.gmail.com","subject":"Re: panic recovery","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-01-16T12:38:54Z","receivedAt":"2011-01-16T12:38:54Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Levend Sayar wrote:\n> git am --abort\n> \n> After that, we saw that all the sources she developed for two weeks\n> are gone.\n\nYou can dig up the lost commits from the HEAD reflog after that, which\nrecords all movements of HEAD.  See\n\n  http://www.kernel.org/pub/software/scm/git/docs/git-reflog.html\n\nThe method you described is usually only applicable if you have truly\nunreachable objects, which happens e.g. if you lost some content that\nwas once staged in the index but never committed.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"159548","messageId":"201101161411.22422.trast@student.ethz.ch","threadId":"26289","inReplyTo":"AANLkTikBjWU_dm1a+2AQyP-bhdO_WtYJ8OdE7Zs3E=kV@mail.gmail.com","subject":"Re: panic recovery","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-01-16T13:11:22Z","receivedAt":"2011-01-16T13:11:22Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"By the way:\n\nLevend Sayar wrote:\n> Yesterday one of my colleague tried to commit her two weeks of work.\n\nIf you really mean she wanted to make the first commit in two weeks,\nthat is just wrong.  Usually you should commit at least every few\nhours, and changes should be small and self-contained.  Even in the\ncase of starting a new project or self-contained module, you should\ncommit a lot so you can go back to an older state if required.  You\ncan use rebase -i later to clean up the work-in-progress commits.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"159559","messageId":"7v62tnmkwx.fsf@alter.siamese.dyndns.org","threadId":"26289","inReplyTo":"AANLkTikBjWU_dm1a+2AQyP-bhdO_WtYJ8OdE7Zs3E=kV@mail.gmail.com","subject":"Re: panic recovery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-17T18:42:38Z","receivedAt":"2011-01-17T18:42:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Levend Sayar <levendsayar@gmail.com> writes:\n\n> Yesterday one of my colleague tried to commit her two weeks of work.\n> Nearly 10 source code files.\n\nOk.\n\n> After an unsuccessful am and apply commands, she tried rebase. And git\n> bothered something like you have to finish your am first.\n\nI do not get this for two reasons.\n\nWhat does \"am\" and \"apply\" have anything to do with committing her own\nwork in her own working tree to begin with? And even if \"am\" and/or\n\"apply\" were the right tools for committing hear work, that would mean she\nhad the changes to be committed neatly made into patch form suitable to be\nfed to these commands, so I would imagine that the recovery is just the\nmatter of \"reset --hard\" followed by attempts to apply those patches again\nand fixing rejects more carefully than the first failed attempt?\n\nA practical suggestion, without knowing what really went wrong, that would\nbe valuable, especially for git beginners but applicable also to git\nexperts, is this. First commit your own work proper before doing anything\nthat may cause conflicts such as merging other's possibly unrelated work\n(e.g. merge, am, ...). Then do such mergy operation to make separate\ncommits. You can do fancy things like combining changes into a single\ncommit _after_ doing so, and it will be much safer because at the worst\ncase you will be unable to achieve the fanciness (e.g. combining the\nchanges) but will have the working results (i.e. a commit with your own\nchanges, and separate commits recording others changes).\n"}]}