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.
Related
enter image description hereHoping to find someone well versed in SVN to assist with a problem that has baffled both me and a colleague well experienced in SVN.
I recently was merging in new content to Trunk. I saw in the dialog box the files I'd edited all scroll down the screen as normal, and then received the 'Merge successful' message.
However, when I looked in Trunk none of the changes were present. In repo browser where you typically can see the author username of the most recent changes as well as the time stamp, it showed a previous merge not made by me.
Baffled, my colleague came to observe the whole process and confirmed that he was seeing the same thing: the merge appearing to succeed, but none of the updates persisting.
Has anyone seen this before, and could anyone offer any advice? I've spent a few hours googling at this point and am exhausting likely culprits.
You won't see merged changes in the repo browser until you commit those changes:
A merge only changes the files in your working copy, not directly in the repository.
Which means you have to first commit your changes.
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 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 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