So, I've created a git repository on the networked drive:
git init --bare --shared
and that works fine. Then, I clone it to a local drive with
git clone z:/testgit
and that also works fine. Then I add a file, stage, and commit
git stage *
git commit -m "test commit"
and that ALSO works fine. BUT! When I try to push to the origin, I get this error.
git push origin
Counting objects: 3, done.
Writing objects: 100% (3/3), 225 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: error: unable to write sha1 filename ./objects/f3/e6e90a7465421306fae05c18153260973542e3: Permission denied
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To z:/testgit14
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'z:/testgit'
When attempting to use git stage * directly on the server (on a non --bare git project) I get similar errors.
I have full access to the drive in file explorer, and even able to initialize the repository with git. SSH shouldn't even apply here since it's not a server, it's a networked drive. Everything I've read about git says that this should work. I've read dozens of "how to's" that all say these exact steps, but no one complaining about permission denied, UNLESS they're talking about SSH public keys missing on servers (which, as I've said, shouldn't apply).
What permissions am I missing? Where should I look for and set the proper permissions?
What happens when you try to create the file that git is complaining about?
echo test > ./objects/f3/e6e90a7465421306fae05c18153260973542e3
It's possible that git is creating a new folder (f3) and the folder is not getting the correct permissions, either due to ACL inheritance misconfiguration or because the local machine is trying to adjust the permissions on newly created folders and getting it wrong.
If it were Linux, it could be because the network drive was connected with the wrong mount options, or the umask was set incorrectly, but I'm not sure whether those are available to be changed on a Windows machine.
Related
Symptoms
I have a git workspace in WSL2 environment. The workspace is located under /mnt/c/workspace/repo where is also visible from Windows by the path C:\workspace\repo.
When I do git push from WSL2 side in the workspace, Git hang up with this message.
Enumerating objects: 39, done.
Counting objects: 100% (39/39), done.
Delta compression using up to 16 threads
Compressing objects: 100% (24/24), done.
Writing objects: 34% (9/26)
This is the other observed behavior and environment information in this context.
I can push these files from Windows side with git for windows without any problems.
I can push several times just after cloning files. It won't work after some of my push operations.
This repository just contains text files. The entire repository size is less than 1MB
I've used this environment for several months but I observed this issue just only for this repository
This problem also happened when I copied entire folder to ~/workspace/repo where is not exposed to Windows directly.
The remote is configured to connect with SSH and use the key under /home/<username>/.ssh
Environment information
Linux image in WSL: 20.04.2 LTS (Focal Fossa)
Git version: 2.25.1
Windows version: Microsoft Windows [Version 10.0.19042.844]
$ git config --global --list
user.email=<my mail address>
user.name=<my name>
http.postbuffer=524288000
Tried workarounds
Configureing http.postBuffer
git config --global http.postBuffer 524288000
I've followed this answer in different question in stackoverflow.
https://stackoverflow.com/a/26663047/3200358
This workaround won't work for me.
Windows permission change attrib -r +s
I've followed this workaround to fix some permission problem in Windows side.
https://stackoverflow.com/a/63483040/3200358
attrib -r +s C:\workspace\repo
This workaround won't work for me.
Tried sudo git push
I've tried sudo git push for in case when git command can't access some lock files.
sudo GIT_SSH_COMMAND='ssh -i /home/<username>/.ssh/id_rsa' git push origin master
This workaround won't work for me.
Using https to push
The error message was changed. But this workaround won't work for me.
$ git push --set-upstream origin master -vvvv
Pushing to https://github.com/kyasbal-1994/<repo-name>.git
Enumerating objects: 39, done.
Counting objects: 100% (39/39), done.
Delta compression using up to 16 threads
Compressing objects: 100% (24/24), done.
Writing objects: 100% (26/26), 5.53 MiB | 7.42 MiB/s, done.
Total 26 (delta 6), reused 0 (delta 0)
POST git-receive-pack (5802813 bytes)
error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)
fatal: the remote end hung up unexpectedly
fatal: the remote end hung up unexpectedly
Everything up-to-date
Have you tried invoking Windows' git from WSL by using the path to the Windows git.exe? In fact you could set up an alias in your .bashrc:
alias wgit='/mnt/c/path\ to\ git/Git/git.exe`
This way, you have a Windows executable dealing with Windows files instead of a Linux executable dealing with Windows files, though I'm a little fuzzy on how things work with the mounting.
However, I'm not sure how user-friendly this may be when entering paths.
Assuming that works, there's probably even a way to write a smart wrapper function in bash that detects which file system the repo is on and invokes the right git executable...
As an alternative, you may have more luck maintaining 2 separate repos (WSL & Windows) and then syncing via push/pulls from a server.
So I'm just learning Git, and can't tell what I'm doing wrong in setting up a local and remote repo for my scripts. Originally, the remote repo was going to live on a fileshare (\server\share$\scripts), but I can't even seem to get this to work on my local machine.
I've done my research, and read up on some of the common pitfalls, but I still can't seem to get files accurately reflected in my remote repo when pushing from the local one.
What I have:
Local Repo: In C:\git, with one file "test.txt" created by:
cd C:\git
git init
echo "Hello World" > test.txt
git add .
git commit
Remote Repo: C:\test
git --bare init
Then, when I specify a remove branch with:
git remote add origin C:\test
git push origin master
It tells me all is fine:
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 315 bytes | 315.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To C:\test
06e076a..62b6130 master -> master
And further git pushes return "Everything up-to-date", but the files are never pushed to the remote repository. Querying the logfile indicates that the push did in fact take place:
commit 62b6130cedef529ef97aec5333fcbee96c5e9a2f (HEAD -> master)
Author: [Redacted]
Date: Wed Jan 24 15:21:37 2018 -0500
TEST COMMIT
So where are the files? I'm on the right branch (master), and I even ran a git config receive.denyCurrentBranch false because some other similar threads suggested this as a fix.
Looking for some guidance here, appreciate any and all help!
Your remote repository is a bare repository. This means there simply is no checked out working tree. Just the git objects and branches and tags.
Having a working tree (aka your files in the most up to date master branch) doesn't make any sense for a remote repository. This is where you store all versions of all your files in one place. How should git know which branch/version/commit to use in the working tree?
I also found this description: Source
git init is for working
git init --bare is for sharing
To get your files back again, you need to clone from there.
git clone C:\test .
This will create a new repository with working tree.
Here are some links:
What's the -practical- difference between a Bare and non-Bare repository?
http://bare-vs-nonbare.gitrecipes.de/
I have set up Win32-OpenSSH on a Windows 10 system, and I am using Git for Windows 2.16.1.
I have created a bare test repository, from which I can clone just fine via the file URL:
git clone file:///c:/test.git
Cloning into 'test'...
remote: Counting objects: 33, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 33 (delta 11), reused 0 (delta 0)
Receiving objects: 100% (33/33), done.
Resolving deltas: 100% (11/11), done.
SSHD is also running fine, I can open a shell from my tablet, and access the repository directory via SFTP:
> sftp oli#localhost
oli#localhost's password:
Connected to oli#localhost.
sftp> pwd
Remote working directory: /C:/Users/Oli
sftp> cd /c:/test.git
sftp> pwd
Remote working directory: /c:/test.git
sftp> ls
HEAD config description hooks info objects packed-refs refs
sftp> bye
But cloning via SSH fails for some reason:
> git clone ssh://oli#localhost:22/c:/test.git
Cloning into 'test'...
oli#localhost's password:
fatal: ''/c:/test.git'' 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.
User "Oli" definitely has the correct access rights, and we have seen above that the repository exists and is a valid Git repository. I also tried many different syntax variants on the path.
I have read every Q/A here on Git/SSH/Windows, and the Git Pro book, and the Git reference, and the OpenSSH manuals, and the Win32-OpenSSH wiki.
What am I missing?
This has been answered by Konstantin in this question (Thanks for the link, Aurel):
The problem is - cmd.exe doesn't understand single-quoted parameters.
Git passes the path to the repository enclosed in single quotes, which does not work in cmd.exe.
This can actually be seen in the Git error message above, if you look close enough:
fatal: ''/c:/test.git'' does not appear to be a git repository
So I have set up the workaround that Konstantin suggested:
create shell scripts gup.sh and grp.sh in my home directory on the server, each containing the single line git-upload-pack.exe $* resp. git-receive-pack.exe $*
use parameter -u 'sh gup.sh' in the initial clone operation (when doing this in cmd.exe, use double quotes...)
configuring the cloned repository with commands git config remote.origin.uploadpack 'sh gup.sh'and git config remote.origin.receivepack 'sh grp.sh'
...and it works.
Sadly, Konstantin's answer is not the accepted one, and the least upvoted one. So if this helps you, too, upvote his answer!
Intent
I intend to establish a version control service in a windows local network.
Test Environment
I have a /root folder where there are 2 repos /foo and /bar
Attempts
I was advised to use a git-daemon service (http://git-scm.com/docs/git-daemon) but it's been more complicated to implement (and works differently) from advertised.
The first guide i found was http://railsware.com/blog/2013/09/19/taming-the-git-daemon-to-quickly-share-git-repository/. I used their git daemon options in the '/root' folder that would serve all repos contained therein:
$ git daemon --base-path=. --export-all --reuseaddr --informative-errors --verbose
I was succesful in cloning an empty repo but when I added some content this the message i got:
$ git clone git://root-ip-addr/bar
Cloning into 'bar'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
fatal: read error: Invalid argument
Receiving objects: 100% (3/3), done.
fatal: error in sideband demultiplexer
Next i found http://www.gitguys.com/topics/creating-a-shared-repository-users-sharing-the-repository/ where they don't even mention the daemon but instead went for a local-folder-as-remote aproach. I still think I need a daemon so what I tried was making my repos bare while adding the -enable:receive-pack option on the daemon.
They advise to use branches on the client machines to commit so I did. I also committed to the master branch to see what happens. In both cases GIT seems to stall.
Here is a screenshot of the client machine attempting to push to the central hub. You can see that it stalls at that point.
Here is a screenshot of the central hub running the daemon.
I can only key in ctrl+c to stop the git daemon altogether after that.
The only way that I've actually gotten it to work was calling the daemon from inside the repo, but that would entail having to do that for every repo (i intend to establish this for hundreds of repos)
I understand that I should dedicate a couple of weeks to thoroughly understanding Git, something that I've postponed for the past 6 months, since I've been able to get by with basic clones, adds and commits.
Having said that, i think there should be more visually constructive guides when attempting to explain the git workflow metaphor.
Thank you for your time.
It seems that it is related to bug #101 (issue 457 on google code) in msysgit and a fix was introduced in Git-1.9.4-preview20140611.
Setting the sendpack.sideband config option and than push again works.
git config --global sendpack.sideband false
git push origin ...
I tried it with this git daemon command
git daemon --base-path=. --export-all --reuseaddr --informative-errors \
--verbose --enable=receive-pack
Using Windows 7, we have a bare GIT repository set up on a network drive so that multiple users can pull/push from it. I am able to create a new working repo on my local and multiple other networked drives. However, when I try to clone a new working repository on the same network drive (different folder) , it fails.
Using TortoiseGIT, after I right-click and choose "GIT Clone", put in all of the necessary paths to my bare repo (the new working repo is already filled in) and hit ok, I get the following error:
Cloning into 'R:\path\to\new\repo'... done.
error: refs/remotes/origin/master does not point to a valid object!
error: Trying to write ref refs/heads/master with nonexistent object 5d2164db2c61efc7a5598f6ff75ed3fbbb12456e
fatal: Cannot update the ref 'HEAD'.
fatal: The remote end hung up unexpectedly git did not exit cleanly (exit code 128)
and it fails to create the repo. It does however build the new folder & ".git" subfolder structure.
It's not a r/w permissions issue because I can r/w any other files, but just cannot seem to create this newly cloned repo. My co-worker cannot either. Even if I got to another folder on the network drive, I still cannot clone the repo successfully. Surprisingly, if I just copy/paste a repo I created in another location, then manually do a "pull", it works and updates successfully.
Any ideas on what to try next? Obviously I've Googled "exit code 128" and "cannot update the ref 'HEAD'" but cannot find a solution to my issue. It's probably something really simple that we are overlooking, but we're just getting started with GIT and this is really causing us headaches...
UPDATE: I just noticed that when I do a manual pull from GIT to my "copy", it is doing a Fast-Forward. Maybe this provides some additional clues?
From R:/path/to/repo
* branch master -> FETCH_HEAD
Updating 5d2164d..d75bdb7
Fast-forward
Files.py | 3 +++
1 file changed, 3 insertions(+)
Success
Git might be trying to do some smart stuff with hardlinks that fails on the network drive. Try using git clone --no-hardlinks /r/path/to/my/repo or git clone file:///r/path/to/my/repo
Please do this via command line in msysgit
git clone /r/path/to/my/repo /r/some/other/path
Further, I would recommend using git from the command line as it is a tool that was designed to be used from the command line. You will be able to find more help, faster, with any issues that come up for you.