I'm not too sure what is going on here, but sometimes a particular file in my repository will change the case of its name. e.g.,:
before: File.h
after: file.h
I don't really care why this is happening, but this causes git to think it is a new file, and then I have to go and change the file name back. Can you just make git ignore case changes?
[edit]
I suspect it is Visual Studio doing something weird with that particular file, because it seems to happen most often when I open and save it after changes. I don't have any way to fix bugs in VS however, but git should be a bit more capable I hope.
Since version 1.5.6 there is an ignorecase option available in the [core] section of .git/config
e.g. add ignorecase = true
To change it for just one repo, from that folder run:
git config core.ignorecase true
To change it globally:
git config --global core.ignorecase true
You can force git to rename the file in a case-only way with this command:
git mv --cached name.txt NAME.TXT
Note this doesn't change the case of the file in your checked out copy on a Windows partition, but git records the casing change and you can commit that change. Future checkouts will use the new casing.
In git version 1.6.1.9 for windows I found that "ignorecase=true' in config was already set by default.
The situation described in the question is now re-occuring with Mac OS X, git version >= 1.7.4 (I think). The cure is to set your ignorecase=false and rename the lowercased files (that git changed that way, not Visual Studio) back to their UsualCase by hand (i.e. 'mv myname MyName').
More info here.
To force git to recognize the change of casing to a file, you can run this command.
Change the File casing however you like
git mv -f mynewapp.sln MyNewApp.sln
The previous command seems to be deprecated now.
From the console: git config core.ignorecase true
Change file name capitalisation
Commit
From the console: git config core.ignorecase false
Step 4 fixed problems checking out branches with a different capitalisation.
Related
I have had git LFS enabled on my repository for a while and it has always worked perfectly. Recently, I have been having issues where my local files are being replaced with links.
As an example, I have a png file that will no longer open because the file format is not supported. Upon opening the file in notepad, I am presented with this.
version https://git-lfs.github.com/spec/v1
oid sha256:733c51c9ee6f0f395f5f042869307154d6ebf6d5d5e3bc10e2af68a432903bf0
size 5104
Many of my files are being replaced with these links and my programs that are accessing these files are throwing errors as they are unable to read them.
I am working in Windows 10, I have git lfs installed, I am using git-bash on the Windows Cmd line. I believe that when I was installing git-bash, I enabled symbolic links, I am unsure if that could potentially be causing the issue.
If you need more information, please let me know. I really appreciate everyone's help!
These are the pointer files that Git LFS uses to track objects. The fact that you're seeing them means that the proper filters for your repository aren't set up. Run git lfs install within your checkout to install the filters both in your repository and in your ~/.gitconfig.
Once you've done that, you can run git lfs checkout to fix the current repository, and then Git LFS should work normally when you check out a branch. If you modify or replace your ~/.gitconfig file, be sure to keep the filter entries that git lfs install inserted there.
The proper commands to set the options are as follows:
git config filter.lfs.process = "git-lfs filter-process"
git config filter.lfs.smudge = "git-lfs smudge -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"
It's much easier to invoke git lfs install, though.
I upgraded to Xcode 7.0 yesterday and now git commit (Command-option 'c' in Xcode) gives this diagnostic:
The local repository already exists and has many commits in it. This is a project I've been working on for an embarrassingly long time.
I did the git commands the diagnostic says but it still gives the same diagnostic. I did git config --global user.name and it returns my real and correct name, and git config --global user.email returns my real and correct email. I did these commands in the directory that contains the .git directory, and also in my home directory because I don't know whether the directory matters. I get the same (correct) response in both. I also did git config -l and everything listed looks correct and nowhere do I see the bad email address quoted in the diagnostic.
Commit in a different project gives the same diagnostic.
Maybe if I knew where that erroneous email address came from I would understand what's going on. Can somebody who understands Xcode git please say what's wrong and how to fix it?
Despite the error message, the problem is not the global .gitconfig. It's the .gitconfig inside the project repo.
Use git config --local to set its user.name and user.email. Or just copy them from the global .gitconfig and paste them into the local .gitconfig.
I have a FAT external disk on which I store my GIT repos and use that reops both on Mac and on Windows. As FAT has no permissions, when I have copied files from local disk to external FAT disk I had git diffs because of the file mode changes. I have solved that with git option using this:
git config core.fileMode false
Now on Mac I don't have git diff, i.e. git diff is clean. But when I go on Windows and do git diff I see this:
I remember I had probles when linking my projects using Xcode 6 after updating the Xcode. My frameworks, the same frameworks that you see in the image above, where in Xcode but were not recognized and linked. So I have removed them an re-added and solved the problem. I guess this is the reason why I have diff. Here is an example of a diff:
Was:
Become:
Why I don't see this diff on Mac? Why I have diffs in iOS framework files and what the diff means (XSym, number [0022], hashcode)?
EDIT:
Seems it is somehow connected with symbolic links on FAT: http://www.tucuxi.org/os-x-vfat/ but I am not certain how to solve my problem of using the same repo on Windows and Mac simultaneously.
Here is explanation of the problem: http://www.tucuxi.org/os-x-vfat/ In two words FAT has no understanding of Symbolic Links and hence when you copy symbolic link onto FAT is tries to mimic with add the content mention is the diff in above images.
Here is the solution:
https://www.kernel.org/pub/software/scm/git/docs/git-config.html In tow words, git core.symlinks config should be set false, so that symbolic links are checked out as small plain files that contain the link text:
git config core.symlinks false
And as a result the diff on Mac will be present too. And BTW the diff in the frameworks files what making them not to work on Xcode.
So in general using GIT on FAT I would recommend to set this global settings for GIT:
git config --global core.fileMode false
git config --global core.symlink false
git config --global core.ignorecase true
Check if it is properly set using:
git config -l
It shows all inherited values from: system, global and local.
Important! Even if you use git config --global core.symlink false, you should still checkout different repo for you OSX and Windows so that the option will take effect. So, basically, you should have 2 repo on your External HDD - one for OSX and one for Windows. Otherwise you still get diffs.
I've got an odd problem. Using Octopress on OS X, which uses a Rakefile (ruby) to setup deployment folders and such with a unique Git repository structure.
The problem is this line:
system "git add -A"
...in the Rakefile generates this error:
fatal: Will not add file alias 'blog/{obmitted-dir-name}/index.html' ('blog/{OMITTED-DIR-NAME}/index.html' already exists in index)
Ok, so this sounds like a casing issue and I should issue:
$ git config core.ignorecase false
Nope, still the same error and I've verified it is set to false now. So then I issue:
$ git config --global core.ignorecase false
Still no go.
And now for the odd part... I can manually change directories to my _deploy/ dir and issue the command manually:
_deploy/$ git add -A
No problem!
I've verified this numerous times... The Ruby Rakefile cannot issue git add -A, whereas I can do it manually.
I even stopped the script directly on that step and did it manually.
Does Ruby have a different Git environment it runs from?
Is OSX case insensitive even with setting that git flag? If so, that's my problem and I'll never be able to deploy from OSX (just like I can't deploy from Windows): I have upper and lower case aliases for 404s to redirect.
It turns out the issue is indeed that OSX is case-insensative (I didn't know this!) - which in turn doesn't allow git to perform the aliases of different casing.
That's the same issue I had on Windows and is why I moved to Linux. Looks like I'll have to keep a Linux VM handy to handle updates to my static blog (Octopress/Jekyll) cause I do have traffic on both casing of the urls.
If you are reading this and want to remain on OSX with mixed-case blog posts, the answer would be to create a virtual disk that has case sensitivity, mount it permanently and move your Octopress/Jekyll install to it. See: https://gist.github.com/dixson3/8360571
As mentioned in the other answer: macOS (standard hard drive partition) is case insensitive. That means your local git should be the same too.
So, do not do git config core.ignorecase false as that will mess up the things more. Also, if you rename a folder to uppercase, git doesn't track the change, except if you change the files included. So, it is very easy to miss that.
The solution that worked for me is:
Copy all the folder in your case "blog" to a safe place.
Delete with git rm -rf both folders ({obmitted-dir-name} and {OMITTED-DIR-NAME}).
Add and commit the changes.
Create the blog folder again and paste your content with the folder name you want to keep.
Add and commit the changes.
You will need to do that in all related branches too.
I have recently decided to take the git plunge, and am really enjoying using git, even on Windows.
My current open source project lives on subversion, all devs are familiar with subversion so I would like to keep subversion as the "source of truth" for now.
Nonetheless, I want to use git, so I went ahead and created a copy of the source on github using git svn. All my work is done against the source in github and I push my changes to github. Once every few days I also push my changes to svn and rebase.
The initial import seemed to go ok, but now every time I do a "git svn rebase" I keep on getting conflicts, even on files I have not changed in my get repository. This is causing me much pain.
Eg.
$ git svn rebase
First, rewinding head to replay your work on top of it...
Applying: Added git ignore file
c:/Users/sam/Desktop/MediaBrowserGit/trunk/.git/rebase-apply/patch:12: trailing
whitespace.
*/obj/*
error: .gitignore: already exists in index
Using index info to reconstruct a base tree...
:12: trailing whitespace.
*/obj/*
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Failed to merge in the changes.
Patch failed at 0001 Added git ignore file
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
rebase refs/remotes/git-svn: command returned error: 1
My questions:
Is there any way I can tell git to sync itself up with svn using svn as the source, so I can start with a clean slate. (export latest, check in changes and reset the svn refs somewhere)
Are there any tips and tricks to getting this scenario to work consistently?
Should I have the core.safecrlf and core.autocrlf options set to true? It seems I will need a bit of hoop jumping.
Related:
http://kerneltrap.org/index.php?q=mailarchive/git/2008/4/16/1450834/thread
http://markmail.org/message/vaois4kkr5ggugqs#query:git%20crlf+page:1+mid:i4flex6vmt5tdala+state:results
http://code.google.com/p/msysgit/issues/detail?id=271
It seems getting line endings right is a bit of a black art.
(I realize that this question probably needs to be expanded, please comment on the places that need expanding)
Are you getting line-ending conflicts? Git has a few configuration properties you can set that change how it handles the end of line characters. I have the following set:
# this makes git NOT attempt to convert line endings on commit and checkout
core.autocrlf=false
# this makes git check if the conversion done by autocrlf would be reversible
# this is probably not required because I do not have autocrlf turned on
core.safecrlf=true
Note that I am on windows, all my coworkers are on windows and I am interfacing with SVN through git-svn. These settings seem to do the trick for me.
(source: codinghorror.com)