panic recovery

Hi, all.

Yesterday one of my colleague tried to commit her two weeks of work. Nearly 10 source code files. After an unsuccessful am and apply commands, she tried rebase. And git bothered something like you have to finish your am first. Then I suggested to do

git am --abort

After that, we saw that all the sources she developed for two weeks are gone. We really got panic.But I know that git stores everthing as objects, namely commit,tree,blob and tag objects.

We sorted every file according to modification time under .git/objects directory and use "git show" for every single object. After a cumbersome work, we found blob objects for our source codes that we lost and commit objects. Namely we rescued her work.

Is there a better way to use in this kind of situations ?

For example, to list every single objects under objects directory according to their types ? Or search a phrase in every blob obejcts to find the source code we are looking for ?

_lvnd_ (^_^)

Levend Sayar wrote:

You can dig up the lost commits from the HEAD reflog after that, which records all movements of HEAD. See

  http://www.kernel.org/pub/software/scm/git/docs/git-reflog.html

The method you described is usually only applicable if you have truly unreachable objects, which happens e.g. if you lost some content that was once staged in the index but never committed.

By the way:

Levend Sayar wrote:

If you really mean she wanted to make the first commit in two weeks, that is just wrong. Usually you should commit at least every few hours, and changes should be small and self-contained. Even in the case of starting a new project or self-contained module, you should commit a lot so you can go back to an older state if required. You can use rebase -i later to clean up the work-in-progress commits.

Levend Sayar <levendsayar@gmail.com> writes:

Ok.

I do not get this for two reasons.

What does "am" and "apply" have anything to do with committing her own work in her own working tree to begin with? And even if "am" and/or "apply" were the right tools for committing hear work, that would mean she had the changes to be committed neatly made into patch form suitable to be fed to these commands, so I would imagine that the recovery is just the matter of "reset --hard" followed by attempts to apply those patches again and fixing rejects more carefully than the first failed attempt?

A practical suggestion, without knowing what really went wrong, that would be valuable, especially for git beginners but applicable also to git experts, is this. First commit your own work proper before doing anything that may cause conflicts such as merging other's possibly unrelated work (e.g. merge, am, ...). Then do such mergy operation to make separate commits. You can do fancy things like combining changes into a single commit _after_ doing so, and it will be much safer because at the worst case you will be unable to achieve the fanciness (e.g. combining the changes) but will have the working results (i.e. a commit with your own changes, and separate commits recording others changes).