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
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 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
I have a Jenkins master on Windows which runs some Windows builds.
The git client plugin in configured with a fixed path to git as "C:\Program Files (x86)\git\bin\git.exe"
I've now created a Linux slave, but when I run a job on there, it's trying to run the command "C:\Program Files (x86)\git\bin\git.exe init", and obviously fails.
Is there a simple solution to this? I think I've resolved it already by modifying PATH on the Windows master, and the fixed path to git is now just "git" so would work on both OSs.
Is the "correct" way to resolve this for Jenkins, or is there another/better way to do this?
Thanks.
My problem was slightly different, but my solution also applies for this question here. Jenkins Poll SCM (Git) on Windows master / Build on Linux slave
When using the "Git installations" option, you will need to create different jobs, one with each Git Installation. Modifying the PATH either on windows or linux, sometimes might not be an option (in my case, I only have access to Jenkins web UI).
Instead, just make the Default Git installation to point to whatever the Master git installation is (e.g. c:\apps\git\bin\git.exe), and then configure the custom "Tool Locations" for each node. This way you can run the same jenkins job in different master/slave OS. Steps:
Manage Jenkins > Manage Nodes
For each node having git location other than the one provided in the "Git installation", do:
2.1 Open node configuration page (Configure icon)
2.2 Check "Tool Locations" if not already checked
2.3 Click "Add"
2.4 Select "(Git) Default" on the dropdown
2.5 Enter the path to the slave node git installation (e.g. /usr/local/bin/git)
2.6 Save
Repeat steps 2.1 to 2.5 for each Linux slave the job may run.
Node configuration on linux should look something like this:
I believe the additional "git installations" are more suitable, as #Jayan mentioned, when you need to have multiple git installations or you need to run, for some reason, a specific version of git for select Jenkins jobs.
Ensuring "git" in the path of all slaves and master is one good way.
However Jenkins can have multiple installation of git (true for other tools such as jdk, groovy...)
You can configure this from http://server-url/configure
Click on "Add Git" and provide new git with different name and path
You can then "select which git to use" in the "jobs" configuration.
This approach has a positive side effect. It will allow you to use different git client versions (say for testing)
The same environment variable for git dir is fine for that.
My issue was Linux master/Windows slave but this could be applicable either way.
The additional behavior Force polling using workspace did the trick for me.
I didn't have the necessary permissions to make the changes in the other solutions. There might be other considerations you need to take before using this behavior so check the plugin docs before implementing.
I am a Git GUI user. I don't have an issue using it for my local development. However, now we have a server with a Git repository. Can I remotely push, pull and diff by using the Git GUI client to access that?
Currently, I am SSHing to the Linux server, and use a Git command to do all the Git commands. But I found it very difficulty when it comes to diff. That's why I think is there any solution for me using the Git GUI client access remote repository and do the Git command with a Git client.
I want to be able to mount a remote server in a Git repository.
Current we only have to open the Git repository in our local disk. For example, the C:\www\repo.git file. How about if I want to access 10.10.10.10/home/www/.git and do all the Git commands in the Git client?
Solutions are open for OS X and Windows.
Aside from VNC / remote X (which is an obvious solution and therefore not worth putting in an answer), the only alternative I can find is Visual Studio Code's new remote development support.
You can connect to a server via ssh (from within Visual Studio Code), and then Visual Studio Code's Git features work natively. The interface is fairly basic however - in particular there is no history view and you can't rebase, cherry-pick, etc. from the GUI. It's basically for staging commits.
This extension gives you a proper git graph view. It's pretty good.
If your server has it enabled, you can use XForwarding to display a GUI executed on the remote machine on your local machine.
On the server-side, this means that you need to have the proper tools installed (e.g., git-gui, which means that you also need Tcl/Tk installed, which means that you also need the X infrastructure installed).
You also must enable Xforwarding, by making sure that you have a line like the following in your /etc/ssh/sshd_config:
X11Forwarding yes
To use that on your local Linux machine, you would usually use the -X flag to enable XForwarding for a given connection:
shiro#local:~$ ssh -X gituser#gitserver
gituser#gitserver:~$ cd repo.git
gituser#gitserver:~/repo.git$ git gui
On your local OS X machine, you would instead use -Y:
shiro#applejoice:~$ ssh -Y gituser#gitserver
gituser#gitserver:~$ cd repo.git
gituser#gitserver:~/repo.git$ git gui
You need an Xserver running on your local machine, in order to use XForwarding. While this is not a problem on Linux (or OS X), it gets complicated for Win32. There are tutorials on the web for setting up and using Xservers under Win32 (e.g., Xming).
First, when it comes to diff, you can simply git fetch your repo, and do the diff locally (with git gui), since you have the all history.
Second, if you have ssh access to the server, you don't need to actually open an ssh session.
A simple git command git#gitserver:/path/to/git/project.git is enough (repalce "command" with clone/push/pull/fetch)
That means the fetch is easy.
See Git on the Server - Setting Up the Server for an ssh setup, at least for Linux or Mac.
For Windows, you have alternative ssh server you can consider, like copssh-free-edition.
But now our team is having this issue, and I am the only person in charge for the GIT. That's why I looks for help how to solve this
Then you would need to ssh to the server, git add and git commit there in the repo, then go back to your local workstation, clone or fetch, and do the diff there. –
There is server running under CentOS with php-fpm and nginx on aboard. Two projects are hosted, one of them is primary, the second contains half of the primary project as symlinks and part corresponding to itself. Both projects are in git repos. The primary project works correct under Linux and Windows machines after cloning the repo. But the second project contains symlinks and it doesn't work properly.
I don't know what to do. It's important to save the symlinks, but how should we work with the second project on Windows? Some hooks with git (replace symlinks with files before pull)?
git converts symlinks to text files on Windows, since symlinks are available only on *nix environments, and msysgit doesn't take care of them by default.
You can create a post-commit hook to workaround them.
Check answers on git symlinks in windows, specifically this one where a user has given steps to handle the scenario.
You are looking for git submodules: http://git-scm.com/docs/git-submodule