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.
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'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.
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.
I have since fixed this problem. But I still don't know why what I did worked.
We have an svn repository for our code at work. I have a local git-svn repository because I <3 Git. :) We use Windows, so I use Cygwin. I think the latest version in Cygwin is Git 1.7.0.4. On Friday, I dcommitted my code without a problem, went home. Monday morning I came back, and tried to 'git svn rebase' because someone had committed code over the weekend (overachievers).
It began normally, and then suddenly decided it couldn't find the trunk. Unfortunately, I lost the exact error message, but it was yelling about not being about to find /refs/remotes/trunk ...and I was very scared. Luckily, though, I had no uncommitted code. Nothing to lose. Nevertheless, every time I tried to 'git svn rebase' after that, it would hang forEVER, and then I would get the following error:
Unable to determine upstream SVN information from working tree history
I researched it for a whole day. I tried changing the svn-remote url from https://xxx.xxx.xxx/xxx/xxx to https://xxx.xxx.xxx/xxx/xxx/ as ridiculous as that seems. I then did a 'git svn fetch' ... and it re-fetched the whole trunk (all 1682 commits). But the rebase still wouldn't work. So I gave up for the day, and decided that the next day I would just create a new repository and start over (which would take a whole day). This morning, I went to ask the question on here before I went unabashedly deleting my repository. I came across this:
git-svn rebase gone horribly wrong
which wasn't exactly my problem, but I decided to try 'git reset --hard trunk' because that's what I wanted. And it worked. Everything is fine now.
However.
Why did it do that in the first place? I didn't change anything as far as I know, as I was not at work over the weekend. What kind of things would have caused that error? I assume I absent-mindedly did something awful, but I need to know what so I don't do it again. :)
Thanks in advance.
This error:
Unable to determine upstream SVN information from working tree history
Sounds like your current git history was not based on the svn history at all, and thus rebase couldn't find a common ancestor.
By changing the URL, I think all the commits have SLIGHTLY different commit messages, and therefore different sha1 hashes, and therefore your old ancestors do not match the new ones, causing rebase to fail.
As to why trunk disappeared/failed, it would be pretty hard to understand what happened without the error message.
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...