I have a Windows PC and on the same PC I have a Lubuntu VM inside the VMWare player.
I share my Windows folders so I can see them from the Lubunutu VM.
My problem is when I clone a Git repo on Windows (using Tortoise Git) and then try to access it from Lubuntu (using Git from command line) all files appear modified although I have not changed them.
I know that reason for this is that Windows and Linux handle the new lines differently.
My question is how can I configure my Git installations on Windows and on Lubuntu so I do not have this problem?
Update:
As suggested (by Craig Estey) this does not seem to be CRLF problem. I tried cloning a repo in my Linux VM on the shared directory and got following error:
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.`
I have no problem cloning the same repo on the VM's local drive.
Any idea what could be the reason?
Note: The main reason I want to do this is to keep my VM's drive size small and use shared drive as much as possible. My VM's local drive is on SSD drive and shared drive is on much larger HDD.
Suppose you put a repository into a Windows Shared folder.
And mount(Mount shared folder on Ubuntu) that shared folder on Ubuntu, so you can clone that repository. (Talking about you can not clone, it must be another problem. I tested it, good for me.)
When you cd to that repository in that mount, you see all files are modified on Ubuntu, then it should be the EOL problem.
On Windows the autocrlf is true by default(assume you are using Git for Windows).
When you clone a repository on Windows, the files will be checkout with CRLF EOL.
But, On Ubuntu the autocrlf is false by default. Using git in that repository which is mount on Ubuntu, git expects the EOL is LF. But, the EOL is still CRLF. That's why git treats all file as modified on Ubuntu.
To fix this problem, make sure both OS to use the same autocrlf value, or using .gitattributes to control the EOL.
For example, using false value:
On windows,
Delete all files in working tree of that repository.
(Note: if you have local changes, commit them first.)
Run git config core.autocrlf false for that repository only. Or
Right click in that repository, click TortoiseGit -> Setting
In Settings dialog, go Git node, select local and un-check the AutoCrlf
Apply the change
Perform git reset hard to get all files back with correct EOLs.
Open TortoiseGit Log Message dialog
Right click on current branch and perform Reset "<current branch name>" to this
Choose "Hard" option
On Ubuntu, you should not see all files modified.
For using .gitattributes:
* -crlf
Related
I'm opening a new worktree in my local repository in Windows, and can't compile it in my Linux virtual machine, because the ".git" contains a full path starting with "C:/Git" that the virtual machine does not recognize.
I have a git repository that I often need to cross-compile on both Windows and Linux.
I originally cloned the repository in my windows system and mounted my "C:" drive as a shared file system in a virtual Ubuntu machine.
This usually works perfectly fine.
When attempting to open a new worktree in git, the linked repository doesn't have it's own ".git" folder, but rather a link to the original repository's ".git" folder, and this is saved as an absolute path, in the following format:
gitdir: C:/Git/...
When attempting to run:
git rev-parse
I get the following message:
fatal: not a git repository: /mnt/hgfs/WindowsDriveC/Git/WorktreeDir/C:/Git/OriginalGitDir/.git/worktrees/WorktreeDir
Due to this limitation, several of my scripts fail.
Is there any way to "trick" Linux into recognizing the full path and properly identifying the original git repo?
Typically, doing this kind of thing is discouraged because it can lead to corruption, and as you've seen the Windows paths don't play well with the Linux paths.
However, that being said, there are a couple of options. One is to set up the worktree under Cygwin or Windows Subsystem for Linux and share it. That will still result in a path that doesn't exist on the Linux VM, but it would be possible to create a symlink from /cygdrive/c or /mnt/c to /mnt/hgfs/WindowsDriveC and then the rest of the stuff would work.
Another option is just to use Windows Subsystem for Linux, which means that you can do your compilation and produce Windows binaries without leaving Windows. You'd produce Linux binaries, but you wouldn't have to worry about sharing with the VM. The worktree would need to be created under WSL, though.
A final option is to edit the .git file in the worktree to use a relative path to the main repository. This is unsupported and might break, but then again it might work for your needs. Be sure to use forward slashes for that purpose.
I use VMware under windows, and centos6.5 is the virtual machine. I use VMTools share folder between windows and centos. I use centos git in the share folder, However, when I git commit, it appears this message. Details as the image
I use centos git in the folder that is not shared, there is no this warning message.
I use windows git int share folder and not shared folder, there are both no this warning messege.
What can I do to avoid this warning message.
In linux > is a valid filename character. This is not outrageous to see in the context of Jupyter notebooks.
A linux user can commit this file to a git repo.
If a windows user then syncs the git repo they'll end up with an error because > is not a valid file name in windows.
Given a shared repository where Jupyter notebooks reside and windows and linux users coexist, is there an optimal/convenient/safe/organized way to avoid this problem?
One solution could be to add git hooks that warns or even stops the user comitting or pushing the code.
So I work with a Linux VM, I have several repos there with code that I run on the VM. I have a Samba share setup on the VM so I can access the repos from a Windows machine and edit them in Windows. There are many reasons why I have this setup but that would be beyond the scope of this question.
The editing experience is rather good but there is one thing left that's an annoyance: I use Atom on Windows to edit my files and it is great at handling changes within a file using git diff internally. However it colors a number of files as having changed when they have not.
To troubleshoot, I opened a command line on the Windows box and ran git status on the repo, it incorrectly showed a ton of files changed when there are actually no uncommitted changes in the repo. I do all of my git operations on the Linux box but it would be nice to at least have consistent status.
Is there some kind of git config on either the Linux or Windows side that I could use to make the two a little more compatible?
Ok, after digging some more, I've found the issue was due to different file mode flags because of my Samba configuration. I was able to fix things by disabling the fileMode option at the repo level:
git config --unset core.fileMode
And setting it globally on the Windows box:
git config --global core.fileMode true
I'm trying to switch from a windows environment to Linux. I'm primarily PHP developer, but I do know quite a bit about other languages such as CSS, XHTML and Javascript. I need a way of editing my files locally because I work in a git repository and need to commit my saves. On windows I used Aptana and PDT. I'd save my files, upload via Aptana, then commit my work with git.
I need to get a work flow going on my Linux machine now. If you know a better way to do this let me know, however my real question is, is there a plugin that allows gedit to upload files instead of working remotely?
git was designed for distributed development and works well as a mechanism for deploying code to a web server.
On your Linux PC, git clone your git repository url. Edit and commit locally and then git push the changes to the git repository. Then, if you have shell access on the server, use git pull to copy the changes to your server.
To ftp sync, you could set up a branch, ftpbranch, that corresponds to what is on the server, and then each time you want to sync ftpbranch with master:
filestoput=`git diff --name-only master ftpbranch`
Now upload the files:
for f in $filestoput; do curl --ftp-create-dirs -T $f ftp://serverurl
Now update ftpbranch indicating these files have been copied to the server:
git checkout ftpbranch; git merge master; git checkout master
When using linux, you can mount the ftp server to a local folder, then opening and save file from that folder will automatically download and upload the file to ftp server.
If you use ubuntu, just click on Places > Connect To Server.... Choose FTP in Service Type dropdown, fill in the required info, then don't forget to bookmark it.
After this, you can open the file directly in any text editor, not just gedit. I would recoment geany for serious programming editor, because it have a lot of neat feature, almost same with Notepad++ in Windows.
But, since you already using git, why not just use git push to get the update and git pull to upload the update? I have long since uploading manually to my server. Git do all the work for me, synchronizing it between servers. Any particular reason why you still need ftp?