I'm using Git Gui and Gitk on Windows. How do I undo a hard reset from within the past two hours?
(Is it possible to do this from these applications, without using the command line?)
I saw this SO post, which says that undos are possible before git's garbage collection occurs. I might have quit and reopened one or both of these applications.
If you had changes in your working tree that were not committed when you did git reset --hard, those changes are gone for ever. You have to use your memory (in your head) to recreate them.
Changes that were committed after the commit to which you switched are not lost. They likely have no reference pointing to them, making them more difficult to locate. The tool to list all low-level changes to the repo is git reflog.
After you locate the commit which you want to revert to observe the hash number in the first row and use git reset --hard #hashnumber or git checkout #hashnumber to get the changes.
I found this useful line on http://quirkygba.blogspot.com/2008/11/recovering-history-with-git-reflog.html:
gitk --all $(git reflog | cut -c1-7)
This will display all the hidden changes in gitk, where you can comfortably view, point, click and create new branches.
As you mentioned the unreferenced commits are normally being kept in the repository for 30 days.
EDIT: I have to add stuff here so that my edit is at least 6 characters. I know, sometimes code fixes are less than 6 characters, but there might, after all, be something else to improve in this post.
See the answers by Brian Riehman and Pat Notz in the link in the question.
One solution is to use the command line.
In Windows, open DOS in the directory containing your .git directory.
Type something like the following to see what commit you want to go to:
"c:\Program Files\Git\bin\git.exe" reflog
To go to a certain commit, type something like the following, where the last expression is the SHA1 code of that commit:
"c:\Program Files\Git\bin\git.exe" reset --hard 5eb4080
I don't think you can undo a hard reset to get uncommitted changes back - you can undo a rebase because the blobs are still available, but if you never committed your newest changes to Git ever, anything it overwrote is most likely history. I'd love to find out that I'm wrong though!
Related
I have 2 branches master, testing. I git checkout testing and added an exclusion in .git/info/exclude
I added this into exclude: MyProject/MyProject.xcodeproj/project.pbxproj
I did this so it wouldnt prompt me to add it and commit it everytime because it changes whenever I change tab or stuff like that.
I committed this to testing and pushed, then I git checkout master and git merge testing.
In the terminal it said this: delete mode 100644 MyProject/MyProject.xcodeproj/project.pbxproj
And after this I cant open my xcode project anymore, it says cannot be opened because it is missing its project.pbxproj file
And now I cant seem to get it back, I cant find it in my github under commits. ;_;
Usually you put this stuff in your .gitignore rather than .git/info/exclude.
To get it back you could check out the commit right before removing it (assuming there is such a commit), move it someplace safe, and then re-add it after switching back to master.
If it's a file that is needed in the repository, then making git ignore it doesn't really make any sense (think of the guy cloning a fresh copy). Perhaps you'll have to live with either committing changes to it all the time, or get into the habit of leaving that file unstaged most of the time.
When Git removes files either through a soft or hard reset - where do these files go? Is there any way to go back to the condition before a mixed reset?
Normally when a file is deleted on an operating system, it goes to a trash can. When files are deleted or removed via Git they seem to go into an ether. Where do these files go?
I have a stack of new files that weren't added properly and I foolishly ran a mixed reset and now these files are no where to be seen.
I'm using SourceTree for OS X by the way.
If you did a --mixed or --soft reset , then the files in your directory would not have gone anywhere because those types of resets do not effect your working tree. With a --hard reset the files in your working tree will be deleted.
Just a small explaination of git reset command usage:
The main parameters are soft, hard and mixed. These tell Git what to do with your index and working copy when performing the reset.
Soft
The --soft parameter tells Git to reset HEAD to another commit, but that’s it. If you specify --soft Git will stop there and nothing else will change. What this means is that the index and working copy don’t get touched, so all of the files that changed between the original HEAD and the commit you reset to appear to be staged.
Mixed (default)
The --mixed parameter (which is the default if you don’t specify anything) will reset HEAD to another commit, and will reset the index to match it, but will stop there. The working copy will not be touched. So, all of the changes between the original HEAD and the commit you reset to are still in the working copy and appear as modified, but not staged.
Hard
The --hard parameter will blow out everything – it resets HEAD back to another commit, resets the index to match it, and resets the working copy to match it as well. This is the more dangerous of the commands and is where you can cause damage. Data might get lost here!
And more thing, You can recover the lost data upto some extent using git reflog.
So, in your case data should be present there only, since you gave --mixed parameter.
When files are deleted or removed via Git they seem to go into an ether. Where do these files go?
When you do a hard reset git will unlink(2) the files.
The data might still be there on the file system but there are no guarantees. Please read https://unix.stackexchange.com/questions/10883 where some recovery tools are mentioned, mostly for ext3.
The git commit, stash and branch commands are often used to save work. Also pay a special attention to the reflog for locating and re-retrieveing runaway leaf changes, especially after a reset.
So, I am working on a project with XCode. Happily, I found out that it keeps an Git repository within every project. So, after a mistake on a code, i just used
git checkout aux.c
to move back from theses mistakes. Unfortunately, as i just found out, Xcode does not auto-commit, so, I ended up with a blank file.
I didn't commited anything after this, but still can't figure out how to undo this checkout.
Sorry, you can't. :-( You're going to have to replace the file some other way.
There are two places where git tracks your files - commits, and the index/staging area. Since there was no commit, and you checked the version of the file out of the staging area, there's no other place it would be.
Do run git status just in case, to make sure it doesn't still show staged changes to that file.
Any chance you had it open in an editor still and could undo the changes to the file that git checkout made? Some editors like Textmate and SublimeText will allow that; others don't.
If the file has never been committed to the repository then unfortunately you are out of luck.
From the sounds of it, you simply have an empty git repository, which will mean your file has been lost and something Versions (which comes with Lion) or Time Machine may be your best bet at recovering from your mistake.
To confirm if anything has been committed to the repository, use git log. If you get an empty response then you're out of luck on the git front.
Unfortunately, this probably this isn't the answer you were looking for.
In fact, undoing a first commit on git is impossible. So, if you are running Xcode, commit manually frequently.
But, there is another way.
If you are running OS X 10.7 Lion or latter (not sure about Snow Leopard), you can try to use the versions feature from OS X to recover any file. Too late for me, but it should work
Best way to recover if your uncommitted changes would be to go to (Left Pane) Source Control Navigator -> Stashed Changes -> Look for a file which dated/timed earlier than your commit which you would like to reverse and click to apply stash changes to the file. That would bring back all the unsaved files back.
My coworker was on one branch, I was on the other. When she merged her branch with mine, my changes did not get in. The source files were "M" (Modified) in Xcode and not "C" (Conflict) so we assumed it was ok. I went back to my branch and I saw that the the code I changed was still there and my code was working fine. Then we thought to try the merge again but being on my branch from my desktop. Same thing showed up where the files were "M" and none were "C".
Again my changes got overriden. So now I'm trying to go back a merge. I tried using the Github tool I downloaded from http://mac.github.com/ by clicking on the most recent commit, and rolling back to that commit, but my changes still seemed to be gone. I do not see the merging of the branches in the history. Is that because I haven't committed after merging?
How can I get back to my branch before I merged?
I haven't used Xcode's version control GUI nor Github tool. If you know the sha1 of the commit which had your changes, you can do this at the command line:
git reset --hard <the sha1>
That will reset your current branch to be at your commit. It will also reset the files in the working tree. Be careful. If you have uncommitted changes, they will be lost.
You can reset the last n number of unpushed commits(commited yet but not pushed). Then command you need to use is
git reset HEAD -- will omit the last commit
git reset HEAD^n -- will omit the n number of last unpushed commits.
Using TortoiseGit (I'm trying to avoid command line usage) how does one delete all commits that accended from a certain commit, and "get back in the past" (example usage: continued doing something, figured I didn't like where it was going, and decided to go "back" disregarding all in between).
In short I wish to go 5 commits "back", and delete them afterwards.
Go to TortoiseGit -> Show log. Select the most recent commit you want to keep, everything above will be erased. Then right click on it and select "Reset "master" to this" and choose Hard. Be careful though because once you do this all the commits after it will be forever lost unless they are stored off in another branch somewhere.
I've never used Tortoise anything (unless you count the electronica group), but I'll give you this info in case you don't find a way to do it with the GUI or you end up deciding to go CLI after all.
As #Tuxified mentions, you can accomplish this with git reset --hard <COMMIT>. You need to specify a commit, which can be done in any of an intimidating panoply of possible ways; the most common have forms like HEAD~4, which specifies a commit 4 commits before the head of the current branch, and deadbeef42, which specifies a commit whose SHA1 starts with 0xdeadbeef42. If you're running linux or OSX, you can get the full details on commit specifiers via man git-rev-parse, under "SPECIFYING REVISIONS".
You can also rename the current branch (git branch -m new_branch_name) and then create a new branch with its head at the place you want to revert to. The advantage is that if you end up wanting to use all or some of the stuff you did there, you can still readily access it; and if you typo the commit, you're saved from a big holycrap moment. Plus git branches are super lightweight so the only real downside is that there will be another branch listed. To make the new master branch you would use git branch master <COMMIT>, and then you check it out. So the net effect here is the same as the first option, except that you still have your old changes saved in the branch new_branch_name. You can even merge those changes back in later, after new commits to master, if you feel like it.
Note that either of these techniques are considered "rewriting history" and will cause issues if you're sharing your repo with others. If you're being smart and pushing to a backup repo in cloud city or another pc, you will have to fix things on that end before you can push to it again.
This is probably way more info than you need right now, but if you end up using git a lot you'll probably want to learn this stuff at some point. Sorry I don't know how to use Tortoise...