I'm having a bit of a problem with Git again and I'm hoping someone can help me.
I've managed to clone a SVN repo using TortoiseGit. Unfortunately, cloned repository doesn't observe a global AutoCRLF setting and it's cloned with AutoCRLF set to false.
Now, I thought I'd clone the cloned repository into a bare Git repo that will be used as the base repo. The cloning seems to go well, but when I try to clone the bare repo, I get an error saying that I'm trying to clone an empty repository.
What am I doing wrong?
I can't *really* help you, but FWIW: I managed to clone WTL svn with , then cloned it to a bare repo, then cloned it to a normal repo.
And on a personal note: I do see a point of multi-platform projects, using core.autocrlf=true, but I'd rather deal with my line endings myself. So, personally, I work with core.autocrlf=false and am quite happy (true, patches have inconsistent line endings, but most of the time they apply fine).
By the way, I've forked your GitHub repo. Did you use core.autocrlf=true when you created it?
and one more thing about Git. Would you push the source of b145 to GitHub and/or SF?
I'm trying to sync my fork with my local repo, but the local repo already has b145 and I don't want to introduce unnecessary merges.
One of the problems I see when I clone my Console SVN repo is that Windows explorer doesn't recognize .sln file's Visual Studio version (I assume it's because of the line endings)
As for pushing b145 to Git repos, I'd like to fix this problem first, recreate the repositories and switch to Git. Would that be a problem for you?
I have just installed the latest Git and TortoiseGit and tried cloning my Console2 SVN repo.
Global AutoCRLF setting is false. Repository's AutoCRLF is false. Line endings are all LF.
The following is the result of my experiments and ***my*** interpretation of on GitHub.
> I've managed to clone a SVN repo using TortoiseGit. Unfortunately, cloned repository doesn't observe a global AutoCRLF setting and it's cloned with AutoCRLF set to false.
If I read this part correctly, you got all the files in the workdir with LF. This is actually **good** thing because AFAICT they want repo with LF's. So the fact that with core.autocrlf=false (no conversion whatsoever) you got all files in workdir with LF's sort of confirms that you got the repo with LF's.
> One of the problems I see when I clone my Console SVN repo is that Windows explorer doesn't recognize .sln file's Visual Studio version (I assume it's because of the line endings)
My experiments confirm that your assumption is correct. The funny thing is that VS can open such solution file just fine. It's actually Visual Studio Version Selector - the one that is associated with .sln files - that gets messed up.
So, as GitHub recommends, you just need to reset your workdir. ***BUT NOT*** the way they recommend. The trick is they're fixing a broken repo, but you have the good repo. So, just remove everything except .git and do
git checkout .
You can experiment with the following sequence (that convinced me that line endings mess up VS Version Selector)
git config core.autocrlf false
git checkout Console2.sln
:: file size ~2.02
:: nothing happens
git config core.autocrlf true
git checkout Console2.sln
:: file size ~2.06
:: VS opens Console2 solution
As I mentioned earlier (or even on a different thread), although I've spent some time working on msysGit and Johannes Schindelin is a big proponent of autocrlf, I still don't believe in it (especially on single-platform repositories), but… hope you'll quickly adjust to Git and will not be sorry about your dark days of SVN :)
: http://help.github.com/dealing-with-lineendings/ "Dealing with line endings"
What would be the preferred procedure then? I see two options:
1. Keep LF line endings in the repo and have people who clone it change their autocrlf to true.
2. Do initial clone, keep autocrlf set to false, convert all line endings to CRLF and commit. That way people don't have to change autocrlf setting when cloning the repository.
I'd go with 1 just because all Git gurus recommend it. It will also avoid CRLF-fixing commit that changes the whole tree, which I probably dislike more than autocrlf.
Ok, I suggest the following:
I have updated FreeImage to latest version, which includes 64-bit patch and added x64 build to Console project. I have also removed external manifest file from the project, since it seems that the linker embeds one.
I'd like to do one final commit to my SVN repo with these changes and recreate Git repos here and on GitHub with the latest export from the SVN repo. After that, we make a switch to Git.
Git repo will store text files with LF line endings and people cloning Git repos will have to set their autocrlfs to true before performing checkout.
How does that sound?
The only thing I don't like is "recreate Git repos".
If you're concerned that line endings are messed up from your last import, I'd give it a try without recreating repos and see if it gives anybody headaches.
If you just don't want to check in same patches in two different systems, you can try to use "git svn rebase" in your git working tree after you checked in changes into SVN.
But… I can also live with recreated repos as long as we switch to Git for good ;)
Git repos that are on SF and GitHub now were created with Cygwin's git-svn and I did have some strange experiences with line-endings (I don't remember the exact scenario, but there was something with checkout, changing autocrlf and having some files marked as changed)
Being somewhat anally retentive when it comes to my code :-) and not being very familiar with git (e.g. rebasing), I'll sleep better if I recreate GIT repos and make a clean switch if that does not create too much problems on your side…
I agree (especially if Cygwin will be out of the picture :)
And by the way, you should get familiar with rebasing. It is The Power ;)
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.