Using the command line or a third-party git manager, I can execute basic git commands like commit, reset and stash with MATLAB open, presumably because I'm working solely on my local branch. As soon as I want to use git checkout somebranch I get the error:
fatal: cannot create directory at [dir]: Permission denied
What's worse is that my current working directory (on the old branch) now has unstaged changes from the branch I wanted to checkout. Other programs simply reload the files from the newly checked out branch. I've tried finding a way to change how MATLAB locks files but to no avail.
MATLAB R2017b
Windows 10 Pro
More Info
The file structure in my git directory is different between the two branches. I think the issue arises from the fact that a deleted sub-directory was in MATLAB's "set path" list.
First, I would recommend
using a separate git (from the latest Git for Windows and a simplified path)
using a separate working tree (meaning a separate folder) with git worktree.
Second, double-check any locking issue with Process Explorer.
Related
I am not very familiar with git as I just use it in the most basic manner. Lately I've been running into this strange behavior which makes no sense to me and causes a huge disturbance in my productivity. For certain branches when I run git pull instead of just getting the latest commits from the remote repository like I expect, I get an ENORMOUS list of modified/deleted/added files as well as an enormous list of untracked files. The branch I am pulling from is our team's master branch. I am just trying to keep my local copy of master in sync. What are these other untracked files showing up as well as these modified files? I didn't touch any of these other files.
What makes the problem worse is that I can't delete these untracked files or anything. I've tried `git clean -fx' and it only removes 3-4 files but still leaves hundreds. At this point I just want to get rid of all of these files, delete the branch, and pull the branch from remote again.
I tried doing the following:
git fetch --all
git reset --hard origin/<remote_branch_name>
but I received an error because Git couldn't create a symbolic link. I am using Git on Windows.
Why is git pull doing this, and what should I do?
EDIT: I was finally able to run the git reset command when I ran my prompt as an admin, but it still doesn't explain this weird git pull behavior.
It seems to me that the 'git pull' action did not complete successfully.
It is possible that you modified some of the files as an admin, and when pulling as non-admin user git tries to modify or delete a file and has no permissions to it.
Therefore you stay in some half baked state.
What do you see when you run git status?
Is there any error in the git pull?
I have two remote repositories. One is private (Bitbucket) and the other public (Github). I had been pushing changes to Bitbucket using Github app and then pushing the same commit to Github repo using Xcode. However, recently I have been unable to PUSH the commits to Github and using SourceTree I get this error message:
This repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/pre-push.
This is how it looks from within SourceTree:
How can I get my Github repo to accept the most recent commits?
You have a pre-push hook which is telling you that you have git-lfs (large file support) enabled for this repository, but that it can't find the git-lfs program on your computer. The solution is to either remove the hook (which is located in .git/hooks/pre-push, as the error message says), or to fix your PATH so that it can find the git-lfs program.
It would have been enough to say that the .git directory is in the original local directory of your repository and you probably need a program like TextWrangler or similar, that shows the hidden files starting with a dot, to be able to see it and delete it by moving it to the trash (right click mouse). It took me one hour to figure out this. I hope no one else have to waste that time.
Here is the instructions for removing the pre-push file using Mac Terminal:
First: cd to the directory that is your local repository for your project. (The main folder that holds .xcodeproj and other files) The .git file is hidden but you can still access it by typing cd .git/hooks in terminal. If you type ls in terminal to view all files within the current directory, you'll notice the pre-push file. Type rm pre-push to remove the file. You should now be able to push to your remote repository. Just be sure to cd .. back a few times to your local directory for your project. Simple as that.
I have a big (more than 1000 files) VS C# project in git. I need to create a small demo project and use ten files from the big project. To create this new project, I added ten files with mklink (symlink) from the big project to the small. All changes in corresponding files in the big and small project are identical. Now I need to add the small project to a different (my own) git repo.
But symlink will not add in git :
(error: readlink("X.cs"): Function not implemented)
How to add the X.cs (symlink) file in git as a regular file?
I need all changes in X.cs (in big project) to be moved to X.cs (small project).
If adding symlinks to the index fails with error error: readlink("..."): Function not implemented, try to find this line in the local or global config:
[core]
symlinks = false
You need to set symlinks = true for a successful push. Default value (=true) if parameter does not exist or is not working correctly and it depends on the settings with which the repository was created.
Hardlinks do not work with GIT, as the file and hardlink are stored as separate files.
It works the same with git version 2.8 or above (I did not check versions less than 2.8)
The current answer(s) are out-of-date and require revision given recent changes.
The solutions given there isn't enough and isn't working.
There are still issues with the latest Git 2.12 on Windows (February 2017, 18 months after the OP's question)
In the context of working on what was called git-new-workdir in 2015 (the ability, form one clone, to have multiple working tree: this ended up being called git worktree), the Git developers were asking how to reference those worktrees from the main cloned repo.
Would they be using ln? or its Windows equivalent mklink?
This thread, at the time, highlighted the issues:
When running on Windows in MinGW, creating symbolic links via ln always failed.
Using mklink instead of ln is the recommended method of creating links on Windows
That might be true, but not ideal: "Git Bash Shell fails to create symbolic links" does mention:
For my setup, that is Git for Windows 2.11.0 installed on Windows 8.1 export MSYS=winsymlinks:nativestrict does the trick as explained here: git-for-windows/pull/156
It's important to launch the Git Bash shell as administrator as on Windows only administrators could create the symbolic links. So, in order to make tar -xf work and create the required symlinks:
Run Git Bash shell as an administrator
Run export MSYS=winsymlinks:nativestrict
Run tar
See also "Git Symlinks in Windows", where the setup now (Git for Windows 2.10+) include symlink support:
You need to specify that during the clone:
git clone -c core.symlinks=true <URL>
And your CMD session needs to be run as admin.
Needless to say imposing that prerequisite on Windows users is a no-go (Windows in enterprise generally come with limited or no privilege elevation)
Yet, PR 156 does represent some Windows support for symlink, released in Git For Windows 2.10 (Sept. 2016).
It is telling that git worktree ended up implementing the multiple working tree reference... by not relying on symbolic links and by making the borrowee and borrowers aware of each other.
When you are done with a linked working tree you can simply delete it.
The working tree's administrative files in the repository will eventually be removed automatically (see gc.pruneworktreesexpire in git config), or you can run git worktree prune in the main or any linked working tree to clean up any stale administrative files.
So no symbolic link there.
git has problems with individual file links but it has no problem with directory symbolic links(mklink /d ). Therefore move your image files to another directory in your big project and create directory link in your git repo to this directory.
See below for example.
P:\denemeler\gitdeneme1>mklink /d linkDirectory P:\puzzles
Created symbolic link : linkDirectory <<===>> P:\puzzles
P:\denemeler\gitdeneme1>git status
On branch master Untracked files:
(use "git add ..." to include in what will be committed)
linkDirectory/
nothing added to commit but untracked files present (use "git add" to
track)
P:\denemeler\gitdeneme1>git add linkDirectory
P:\denemeler\gitdeneme1>git status
On branch master Changes to be
committed: (use "git reset HEAD ..." to unstage)
new file: linkDirectory/Juggle Fest Question.txt
new file: linkDirectory/jugglefest.txt
new file: linkDirectory/triangle.txt
new file: linkDirectory/triangleQuestion.txt
P:\denemeler\gitdeneme1>git commit -m "new files"
[master 0c7d126] new
files 4 files changed, 14150 insertions(+) create mode 100644
linkDirectory/Juggle Fest Question.txt create mode 100644
linkDirectory/jugglefest.txt create mode 100644
linkDirectory/triangle.txt create mode 100644
linkDirectory/triangleQuestion.txt
P:\denemeler\gitdeneme1>echo "aa" > p:\puzzles\newFile.txt
P:\denemeler\gitdeneme1>git status
On branch master Untracked files:
(use "git add ..." to include in what will be committed)
linkDirectory/newFile.txt
nothing added to commit but untracked files present (use "git add" to
track)
Git does indeed have trouble with symlinks on Windows. However, I don't think you even need symlinks for your problem. A simple workaround is to write a small *.bat script to copy the files in question from one repository to another on demand. With symlink, you don't need to run a script, which saves you a few seconds, but you get a problem that you can accidentally change file in small repository and have unwanted modification in big repository.
Looks like all your simlinks located in one ntfs partition, if it is true, you can renew all simlinks to hardlinks, by some script with command, mklink /h...
Hardlinks friendly for any CVS.
I have just recently backed-up my XCode C++ project on my pendrive, using
rsync -avu
Since then, the version control for my project is grayed-out on every files, I can modify the files and not see the "M" nor the "A" sign. The only files still having version-control working "shared" files for which it works correctly. (Those shared files belong to a different project called "Shared").
I have tried git commit -m, git add . and even git init where the files were. Nothing worked.
Can you please help restoring version control for my project?
UPDATE:
Answers for the questions in commens (and answers):
my git repository is on my local hard drive.
I went to the Organiser-repository pane in XCode and I see my recent git commit -m "sth" as "sth" az a commit. I have a single branch: master.
Im not sure what command would be good to test git, as my commits work (theoretically).
I have a folder named .git in the project folder.
git log is working, showing the same as XCode Organiser-repository pane.
I think the XCode just can't synchronise with the git for some reason, and I don't know how to correct that.
First off, this is not an answer that will fix your problem, I just try to provide some help that might get you closer to a diagnosis.
Git stores its files in a folder named .git. Check if this folder is present in your project. If it's not then your Git repository is gone.
Next, try some basic command such as git log. For this to work, you must first cd to your project folder (or a subfolder thereof), because whenever you run a Git command it will look for the .git folder in the cwd or a parent folder. If git log does not work then your Git repository is broken in some way. Someone else will have to step in to further diagnose the problem, as I am no expert on this subject.
Finally, you should also check whether your rsync command has really sync'ed your project's .git folder with the backup's .git folder. Use this command:
diff -rq /path/to/project/.git /path/to/backup/.git
If there is no difference (as I would expect if rsync has worked correctly) then the problem with your Git repository is both in your project and in your backup. If there are differences then it might be worthwile to try your next steps on a copy of the backup (it should be fine to make the copy in the Finder).
Good luck.
I am a complete Noob when it comes to GIT. I have been just taking my first steps over the last few days. I setup a repo on my laptop, pulled down the Trunk from an SVN project (had some issues with branches, not got them working), but all seems ok there.
I now want to be able to pull or push from the laptop to my main desktop. The reason being the laptop is handy on the train as I spend 2 hours a day travelling and can get some good work done. But my main machine at home is great for development. So I want to be able to push / pull from the laptop to the main computer when I get home. I thought the most simple way of doing this would be to just have the code folder shared out across the LAN and do:
git clone file://192.168.10.51/code
unfortunately this doesn't seem to be working for me:
so I open a git bash cmd and type the above command, I am in C:\code (the shared folder for both machines) this is what I get back:
Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
How can I share the repository between the two machines in the most simple of ways.
There will be other locations that will be official storage points and places where the other devs and CI server etc will pull from, this is just so that I can work on the same repo across two machines.
As per Sebastian's suggestion I get the following:
C:\code>git clone --no-hardlinks file://192.168.10.51/code
Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
**EDIT - ANSWER **
Thanks to all that helped. I tried the mapping a drive and that worked so thought I would go back and retry without mapping. The final result was:
git clone file://\\\\192.168.0.51\code
This worked great.
Thanks
You can specify the remote’s URL by applying the UNC path to the file protocol. This requires you to use four slashes:
git clone file:////<host>/<share>/<path>
For example, if your main machine has the IP 192.168.10.51 and the computer name main, and it has a share named code which itself is a git repository, then both of the following commands should work equally:
git clone file:////main/code
git clone file:////192.168.10.51/code
If the Git repository is in a subdirectory, simply append the path:
git clone file:////main/code/project-repository
git clone file:////192.168.10.51/code/project-repository
$ git clone --no-hardlinks /path/to/repo
The above command uses POSIX path notation for the directory with your git repository. For Windows it is (directory C:/path/to/repo contains .git directory):
C:\some\dir\> git clone --local file:///C:/path/to/repo my_project
The repository will be clone to C:\some\dir\my_project. If you omit file:/// part then --local option is implied.
the answer with the host name didn't work for me
but this did :
git clone file:////home/git/repositories/MyProject.git/
I was successful in doing this using file://, but with one additional slash to denote an absolute path.
git clone file:///cygdrive/c/path/to/repository/
In my case I'm using Git on Cygwin for Windows, which you can see because of the /cygdrive/c part in my paths. With some tweaking to the path it should work with any git installation.
Adding a remote works the same way
git remote add remotename file:///cygdrive/c/path/to/repository/
Maybe map the share as a network drive and then do
git clone Z:\
Mostly just a guess; I always do this stuff using ssh. Following that suggstion of course will mean that you'll need to have that drive mapped every time you push/pull to/from the laptop. I'm not sure how you rig up ssh to work under windows but if you're going to be doing this a lot it might be worth investigating.
Not sure if it was because of my git version (1.7.2) or what, but the approaches listed above using machine name and IP options were not working for me. An additional detail that may/may not be important is that the repo was a bare repo that I had initialized and pushed to from a different machine.
I was trying to clone project1 as advised above with commands like:
$ git clone file:////<IP_ADDRESS>/home/user/git/project1
Cloning into project1...
fatal: '//<IP_ADDRESS>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
and
$ git clone file:////<MACHINE_NAME>/home/user/git/project1
Cloning into project1...
fatal: '//<MACHINE_NAME>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
What did work for me was something simpler:
$ git clone ../git/project1
Cloning into project1...
done.
Note - even though the repo being cloned from was bare, this did produce a 'normal' clone with all the actual code/image/resource files that I was hoping for (as opposed to the internals of the git repo).
Either enter absolute paths or relative paths.
For example the first one below uses absolute paths :
(this is from inside the folder which contains the repository and the backup as subfolders. also remember that the backup folder is not modified if it already contains anything. and if it is not present, a new folder will be created )
~/git$ git clone --no-hardlinks ~/git/git_test1/ ~/git/bkp_repos/
The following uses relative paths :
~/git$ git clone --no-hardlinks git_test1/ bkp_repos2/
While UNC path is supported since Git 2.21 (Feb. 2019, see below), Git 2.24 (Q4 2019) will allow
git clone file://192.168.10.51/code
No more file:////xxx, 'file://' is enough to refer to an UNC path share.
See "Git Fetch Error with UNC".
Note, since 2016 and the MingW-64 git.exe packaged with Git for Windows, an UNC path is supported.
(See "How are msys, msys2, and MinGW-64 related to each other?")
And with Git 2.21 (Feb. 2019), this support extends even in in an msys2 shell (with quotes around the UNC path).
See commit 9e9da23, commit 5440df4 (17 Jan 2019) by Johannes Schindelin (dscho).
Helped-by: Kim Gybels (Jeff-G).
(Merged by Junio C Hamano -- gitster -- in commit f5dd919, 05 Feb 2019)
Before Git 2.21, due to a quirk in Git's method to spawn git-upload-pack, there is a
problem when passing paths with backslashes in them: Git will force the
command-line through the shell, which has different quoting semantics in
Git for Windows (being an MSYS2 program) than regular Win32 executables
such as git.exe itself.
The symptom is that the first of the two backslashes in UNC paths of the
form \\myserver\folder\repository.git is stripped off.
This is mitigated now:
mingw: special-case arguments to sh
The MSYS2 runtime does its best to emulate the command-line wildcard expansion and de-quoting which would be performed by the calling Unix shell on Unix systems.
Those Unix shell quoting rules differ from the quoting rules applying to Windows' cmd and Powershell, making it a little awkward to quote command-line parameters properly when spawning other processes.
In particular, git.exe passes arguments to subprocesses that are not intended to be interpreted as wildcards, and if they contain backslashes, those are not to be interpreted as escape characters, e.g. when passing Windows paths.
Note: this is only a problem when calling MSYS2 executables, not when calling MINGW executables such as git.exe. However, we do call MSYS2 executables frequently, most notably when setting the use_shell flag in the child_process structure.
There is no elegant way to determine whether the .exe file to be executed is an MSYS2 program or a MINGW one.
But since the use case of passing a command line through the shell is so prevalent, we need to work around this issue at least when executing sh.exe.
Let's introduce an ugly, hard-coded test whether argv[0] is "sh", and
whether it refers to the MSYS2 Bash, to determine whether we need to
quote the arguments differently than usual.
That still does not fix the issue completely, but at least it is something.
Incidentally, this also fixes the problem where git clone \\server\repo failed due to incorrect handling of the backslashes when handing the path to the git-upload-pack process.
Further, we need to take care to quote not only whitespace and backslashes, but also curly brackets.
As aliases frequently go through the MSYS2 Bash, and as aliases frequently get parameters such as HEAD#{yesterday}, this is really important.
See t/t5580-clone-push-unc.sh
After clone, for me push wasn't working.
Solution:
Where repo is cloned open .git folder and config file.
For remote origin url set value:
[remote "origin"]
url = file:///C:/Documentation/git_server/kurmisoftware