tags:

views:

41

answers:

1

So. I'm new to git. And I think I may have broken something beyond my ability to repair (hooray).

Here's the breakdown:

I made a remote directory, and accidentally included some VERY large files in the initial commit. This made it difficult for people to do anything with it. (I didn't realize at first, and had made modifications, and had been using the directory on my own for awhile)

I learned that merely removing the files and commiting the removal doesn't help with people cloning the directory, and learned about modifying the history through commands like:

git filter-branch --tree-filter 'rm -f public/vidos/*' HEAD

which would, to my knowledge, remove all files from the public/vidos/ directory, and get rid of all memory of them.

This seemed to happen. I could clone things succesfully (no out of memory errors), and the cloned copy didn't have the super large files in them.

THEN, this morning, (after stupidly making sure I matched the remote depository exactly (i.e. got rid of all my local stuff, thinking it should be up to date for everything except those large files) I started to do work with the directory, and realized that all files seem to be as they were on the initial check in (no modifications, and there are a LOT of things I modified, are showing up)

I did

git log

to look at all modifications, and could see all my commits (including the commits that removed the super large files from the directory). Then I did

git reset hashcode

to rollback to the appropriate git (with the hashcode I got from log).

Except... even though it thinks that I'm at the right commit, the FILES are still identical to the ones I first turned in.

I can look back at my history and SEE that I didn't filter-branch on any of the files that are currently unmodified...and I'm REALLY confused as to why my changes are not there anymore. I commited...I pushed... I was pretty sure the remote repository had all my changes (could check it out (would take forever and run out of memory, but I'd get the files) and SEE the changes......but I can't see them anymore.

Did I do something dumb? Does messing with the history do things I wasn't aware of? Is it entirely impossible that the things I described doing messed up my repository? (i.e. should I be looking in an entirely different direction?)

I really, REALLY want to get my modifications back... replicating all that code (and remembering what I even DID) is going to be very difficult. Is there ANYTHING I can do?

EDIT:

~~~~~~~~~~~ Okay, reset didn't work, but doing:

git checkout hashcode

seems to work just fine, and I can see my code changes.

But, checkout means I'm not in any branch, and I can't them commit these changes to be the most "recent" (it thinks it's up-to-date). Any ideas on how I can make this commit to be "head"? And once it is head, will that get rid of the branch filtering I did to get rid of the super big files? And if it does, does anybody have any advice on how to get rid of those super big files WITHOUT this headache again.

If there is no other way, can I simply checkout two copies (one at head, one at my last good commit) and manually copy and paste the good files into the head, then commit? Seems like it would work, but not be very clean.

+1  A: 

Basically,

 git checkout hashcode

does what I thought git reset would. I'm not sure WHY the changes got rolled back when I branch filtered, but now that I can at least see the code again, I just manually copied the changes into a clone of the head, then rechecked the changes in again. Not the most elegant solution, but I got to keep my filtering AND have the latest code.

I think part of what probably happened was my incomplete understanding of git repositories. I'd never really managed one before, but I had this half-concieved notion that a git repository is always "up to date", and that it has the latest version of things. When i did the branch filtering, I was in the git repository, and I noticed that the filters were in the git status as needing to be commited. So I did. Likely the repository wasn't actually "up to date", and so in commiting (and overriding things blithely) I probably overwrote changes and essentially rolled things back.

Jenny
git reset only resets the index; you wanted git reset --hard.
Ben Stiglitz