This is a rather embarrassing question, but I am rather pressed for time, and can get on with other work while someone far more knowledgeable in Git than me could answer it in seconds.
I've just done a fetch from a remote repo, but I have no working copy files. I'm using Git GUI on Windows, and I can visualise the history, and at some point I could see the file structure of the solution, but I can't find how again. Most operations require me to select a revision, but none are available in the dropdown, and HEAD is not a valid revision for some reason. How do I get the actual source files I need?
The idea is to use a commit to:
checkout it (which will create the working tree)
create a local branch
See How can I switch my git repository to a particular commit:
git checkout -b new_branch 6e559cb
That commit would be the "start point revision" mentioned by Adrian Shum in his answer.
Then please checkout (git checkout) to have your working copy.
You can provide the start point revision to checkout.
Related
I am new to Git. I wrongly uploaded my code into GitHub repository with push command using Xcode source control. Then I asked a question that how can I delete the content of the master, because I thought that deleting files is enough to have a fresh start. (NB: I cannot delete the repository and create a new one) so I deleted every single file in repository with push command and the repository is empty now. When I try to pull my local working copy this time, my local working copy got deleted.
Does anyone know how can I pull my code?
There are two ways to go about fixing this problem.
Rewrite your history and push the rewrite to master (not recommended, because it will screw up everyone else's history as well, but has the benefit if making it appear that you never made a mistake)
Make a new commit reverting your changes and push this new commit. This keeps your old code in the repository but removes it from subsequent versions. It also has the added benefit of not screwing up everyone else's history.
To accomplish #1, simply run git log and find the commit ID number, then run git reset NUMBER to revert your tree to the working state. Then push your changes with git push RemoteName BranchName --force
As I mentioned, I strongly recommend against doing that unless you have some major privacy concerns over your mistake. A much better way to handle the problem is to run git revert CommitID to create a new commit that "undoes" your previous mistake. Check out this Atlassian blurb for a bit on how to do that.
I think I've done something rather stupid which may have cost me a couple of days of work. What follows is a question not so much about GIT itself as how to recover some files I have lost in the process of trying to use Git on a Mac.
I have been using Atlassian Sourcetree to make Git commits and pushes and to work with other members on a team. I have only been committing, pushing and pulling from Git.
As I've mentioned, I've been using SourceTree, but I wanted to evaluate Github for Mac as well.
At the time, I had made some changes to the files in my Git repo, representing about six hours of work. I did NOT commit or push these changes.
After I installed Github, I stupidly set Github to clone the repo to the same folder on my Mac as I had been making my changes in... essentially, Github downloaded the repo and overwrote all of my changes.
There were some files that were overwritten, and some new files that I created that were deleted.
Is there is a way to retrieve these files, either by some Git-based voodoo or some aspect of Mac OS X journaling that I'm not aware of? I would really appreciate hearing about it if there is.
So, from what I remember from having my life destroyed by my stupidity with git, it has a place where you can find your old code.
Go to your main repo folder and then type cd .git/lost-found/other/ or cd .git/lost-found/
You should be able to find a set of files that were older and you can then manually get them back by copying them in.
Here's some more links on it :
Recovering added file after doing git reset --hard HEAD^
Undo a git pull
http://www.quora.com/Git-revision-control/How-can-I-recover-a-file-I-deleted-in-my-local-repo-from-the-remote-repo-in-Git
I have an emergency issue at hand.
First off, yes, I realize this was a very silly mistake.
Earlier on, I had a sync conflict, solved it correctly, and moved on. I just put in about 4 hours of work, saved everything fine, and then went to push to GitHub (using GitHub for Mac client). When I did so, it said there was an error, and I noticed I was on a branch called "HEAD". I then clicked to switch branches, and immediately panicked as I realized all of my changes were gone (since I had switched branches).
Is there ANY way I can switch back to this and recover my information??
If anyone could please help, it'd be greatly appreciated!
Thanks.
Based on the very good explanation on what happened from master branch and 'origin/master' have diverged, how to 'undiverge' branches'? give the following merge a try:
Check out a new branch based on you HEAD
git checkout -b local_changes HEAD
and try to merge the remote branch
git merge origin/ryan
You may experience some merge conflicts that you have to resolve depending on what changed on both sides. If all is fine bring the merges back into you ryan branch again.
git checkout ryan
git merge local_changes
If everything works you should have all the changes in place be able to push again to your remote.
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!
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...