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
Related
After working on something for a while, I thought I should put it in a git repo. Using gitlab, I created a new repo and cloned it from the command line onto my Windows 7 machine. This created a folder with a .git folder in it. I then copied all the files I'd been working on into the folder. I then noticed that the command line where I had cloned the repo was asking for a password. I entered the wrong password a couple of times and stupidly hit ctrl+c. Next thing I knew, the folder with all my files was gone. It is not in the recycle bin. Is there any way to restore these files?
Unfortunately, they are lost and git won't help you here. You should rely on file recovery tools to help you recover the files (long, hard and boring process) if you can afford to rewrite your code from scratch.
Buy I could tell you what you did wrong with git and what you should have done to never have been in such a situation...
You should have done :
1. Create a local repository in your project directory with 'git init'.
2. Do as much development and commits as you want (but at least one...). You are now protected against file deletion!
3. Once you think it worth to be shared, like you do, create the repository in gitlab.
4. Add the gitlab repository as a remote in your local repository.
5. Push the history to the gitlab central repository.
Like that, you should have avoided all the risky action you did and your work is secured at all times.
Standard methods for removed file restoration apply:
Suspend any user operations on the HD (don't create/copy/remove files). This will increase your chances when trying to restore.
Check if you have the file copies/originals in other folders. You mentioned that you had copied them previously into git folder. May you have them in the original directory?
Do you have any backup system running (like Crashplan, etc) ? Check if you have a backup of the files
If nothing of the previous helped proceed to the undelete operation - use dedicated utilities like this one for ex.: http://www.ntfsundelete.com
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.
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.
I'm seriously about to stop coding and become a carpenter. This problem has had me stressed out for quite some time now and there doesn't seem to be any clear solution, other than forcing non-windows machines to use the file permissions windows seems to inflict.
Let's begin with the scenario. I have 2 development machines, one running Windows7, the other Mac OSX. They both are using Eclipse and EGit, and both have cloned the same project from a remote repo. That's where the similarities end, because my windows machine has a nasty habit of retaining a file mode of 644 (r-xr--r--) on its local repo, while the mode on the Mac defaults to a cool 775 (rwxrwxr--x).
So the problem's obviously the file permissions - GIT reports there are files that have changed due to differences in file modes and not actual content. The solution seemed obvious, run the following commands:
git config core.filemode false
git config --global core.filemode false
...which worked like a charm, except when committing and merging resolved conflicts.
For example, say files A, B and C exist on both the Windows and Mac repos. Next, let's change the file mode for these 3 files on the Mac machine so that the developer can edit them. Now change some of the contents in file A. Because we're ignoring the file modes (thanks to the commands above) only file A will be committed and pushed, ready for the Windows machine to fetch, merge and enjoy...
Now, let's edit file A again on the Mac and on the Windows machines, effectively causing a potential conflict, and let the Windows machine commit and push file A first. Then, when the Mac user commits their changes to file A and fetches the latest changes from the remote repo, a conflict is obviously created.
After resolving the conflict on the Mac machine and adding file A back to their local repo, committing that merge includes the previously ignored files B and C, and thus highlighting my problem! Why are the previously ignored files being included in this merge commit? This doesn't seem to be a Mac / Windows problem exclusively, as this problem can be recreated both ways...
This probably wouldn't matter if there were only 3 files, but this project I'm referring to includes thousands, and all these up and down push and pulls are insane. Am I missing something really obvious? Any help will be greatly appreciated!
So after a long and often frustrating run with trying to get Windows and Mac OS machines to like each other when comparing notes and changes over Git, it seems to just be the functionality of Git itself that's driven me mad, and a better understanding of how to better use Git seems to be the final answer.
Originally, I wanted to know how to continue ignoring file-mode changes (which Windows seemed to love updating with its own idea of what permissions and modes should be) while I was resolving conflicts created from updates to the files from someone else. Short answer: you can't. It's just the way Git works.
So how would you deal with this situation when it came up? Short answer again: use branching.
In my original way of using Git, I was continually working on my master branch on my local repo - bad idea already - so all my work would be committed there and all conflict resolution would need to be handled there too, forcing all files to be compared again and all permissions and file modes to come into question.
With branching, you work on another branch, commit to that branch, pull updates to your master branch, and merge you other branch with your master branch after that. Suddenly no more conflicts on the master from the remote repo, and you're winning!
Commands to do this (creating a branch from currently selected branch):
git branch newbranch
To checkout your new branch:
git checkout newbranch
To merge your new branch with your master branch (after you've committed to your newbranch, switch to the master first):
git checkout master
git merge newbranch
Hope this helps someone! -:)
well tbh, I'm not sure how you arrived at your conclusion since the obvious problem is git is not ignoring the file mode changes. This happens to us here too.
if you set that flag it seems to make no difference in some cases and still uses file modes to determine changed files.
that has to be a bug in git, what else could it be?
possibly your answer does not explain the rationale, therefore I dont think it's the correct answer, it's a workaround.
the correct answer is that git doesnt use filemode when it's told not to, it's obviously ignoring that and doing it anyway.
can you explain otherwise.
I'm doing a single developer Visual Studio solution and reached a point where I'd like to incorporate Versioning Control. Several posts address this issue, but one problem I'm facing is a large merge. I have a production copy of the solution and a beta copy. They are NOT dramatically different, but they will require a number of interactions I suspect. I'm using TortoiseSVN and have imported the production version.
Yes, I know I should have used Version Control from the start, but that is hind sight. Would it be best practice to simply use the beta as a reference and work the interations from scratch. Or should I branch off and import the beta separately, then attempt to merge the change. Or is there another alternative I'm missing.
Thanks,
dgp
well, I have experienced SVN in the past ... and I must say, it's lovely cause it's really easy to understand the concept, but it's awful terrible when things pass from the plain commit.
I'm currently using GIT (to host small code on GitHub) and Mercurial (Hg) (I use Kiln in the company - was recommended by myself so they can start using - and in BitBucket for personal use)
I have used SVN for more than a hole year and every time I need something from "the past" or to merge something, it was a nightmare, but the server/client concept was really a break deal and extremely easy to get it... but I found my self, over and over to do merging by hand :(
When GIT started to be hot, I was afraid to move as, dang! SVN was a pain, why should be different in a DVCS?
This videos rocked my world, [ part 1 part 2 ], only then I understood DVCS vs VCS and it was with this that I moved COMPLETELY to DVCS and never go back... proudly!
For your problem, I would install git (or hg), and then create a repository on the folder you have your current source with:
git init will tell your folder, "Hey, I'm a GIT Repo"
git add . let's add all files and folders to be tracked by git
git commit -m "initial commit" let's save all the hard work :)
So, now you have a tracked code, you can simple create a branch and overwrite all your files. YES, worry not, you don't need to have copies of your code in a folder called branch ;) no more copies! all is in the GIT database
then, after creating the branch, changed the files, added all files to be tracked on that branch and committed, safely do a merge :)
ohh, and you don't need a server connection to do all this, all you need is a computer with GIT installed... no more connection dependencies! DVCS is cool or what?! :D