I need your help, actually I have installed git on my debian server then create my remote repository on it. And I have also installed tortoisegit on my windows client.
I have cloned my repository from my debian server to my windows client without problem but I facing a problem, when I make modification on my local repository(windows client) and try to push to my remote repository (debian server) using TortoiseGit.
It stuck at:
git.exe push --progress "origin" master:master
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 249 bytes | 62.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
And can't close the window, have the progress bar, I have only one option "abort".
Can someone have been confronted to similar situation? Or can someone help me please?
Try the same push using the command line, with a simplified PATH and a portable Git (like PortableGit-2.20.1-64-bit.7z.exe) uncompressed anywhere you want.
set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\
set GH=C:\path\to\git
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%PATH%
See if the push succeeds there.
If not, check the state of the remote repo by connecting to the server, and running a git status in the target bare repo.
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.
I am new to Git and Github; and I came across a problem. There is a similiar question here (git bash failed to load advapi32.dll), but they are experiencing a different problem and there are no answers either. I have searched online and was unable to fix this. Here is the issue:
I am using Git Bash to push/pull commits to Github. When I try to push my work, I get this error saying "failed to load advapi32.dll ". I do have this file in my registry. The full Git message is bellow. It is worth noting here, that despite this error, Git is uploading and downloading commits perfectly fine; I just want to fix this problem in case it causes more issues in the future.
$ git push origin master
failed to load advapi32.dll
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 418 bytes | 418.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/khash021/reflections.git
98a7bd9..b982ba4 master -> master
Thanks,
Khash
This problem occurs because the credential halper has been set to wincred and you do not have wincred installed. To verify this, run the command
git config --global credential.helper
if the result says "wincred", this is your problem. To unset the credential helper, run the command:
git config --global --unset credential.helper
That should solve the problem.
First, check your Git version: if it was v2.16.1.windows.2, from 4 days ago, it was quite buggy.
Try with the one released today: v2.16.1.windows.3: uncompress PortableGit-2.16.1.3-64-bit.7z.exe anywhere you want, and define a simplified PATH for testing.
well you could adding the flag:
$ git push origin master --all
Also, given that the .dll file is a system file, check that git has the permission to access it.
each time I try to do the git push heroku master I seem that everything works, but after a couple of hour it fails.
The error message is:
$ git push heroku master
Counting objects: 599, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (318/318), done.
remote: fatal: early EOF
Writing objects: 100% (599/599), 552.65 MiB | 56.00 KiB/s, done.
Total 599 (delta 170), reused 585 (delta 163)
error: unpack failed: index-pack abnormal exit
To https://git.heroku.com/foo.git
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'https://git.heroku.com/foo.git'
Can't solve the error, and it takes a long time before it fails each time I try.
Is the first time I'm going to deploy a project, I would also apreciate some advise if there is something better (and/or cheaper) than heroku for uploading a rails project. And a good tutorial to follow, because I need to use a custom domain (.com) and everything, and at this point I'm not sure what I have to do.
I followed this tutorial for heroku:
https://devcenter.heroku.com/articles/getting-started-with-rails5
Edit: I checked since the first time I tried to upload to heroku, and now I see that the first time the error was different, and since then always the same error I commented before. This is the first error:
git push heroku master
Counting objects: 580, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (462/462), done.
error: unable to rewind rpc post data - try increasing http.postBuffer
error: RPC failed; result=56, HTTP code = 0
fatal: The remote end hung up unexpectedly | 0 bytes/s
Writing objects: 100% (580/580), 552.65 MiB | 240.00 KiB/s, done.
Total 580 (delta 155), reused 0 (delta 0)
fatal: The remote end hung up unexpectedly
Everything up-to-date
It seems a problem with git in your case. You could try to run the git repack command or to clone your repository again, and then deploy to Heroku. If this still fails, perhaps it'd be a good idea to contact their support.
I think that if you are deploying a project for the first time, I think Heroku is the easiest way, but this is my opinion. Adding your custom domain to it is faily easy too, you can check how to do it here.
I contacted the heroku support, and they told me kindly what I was doing something wrong.
It seems that my project folder was 1,2GB, and with the .gitignore it was about 550MB. And in a free account I only can push 500MB maximum.
I looked folder by folder and file by file how many space are they using. And surprisingly it was about 50MB.
The other 500MB to the 550MB were hidden files inside the project which I didn't know anything. Maybe git files, I don't know.
So I copied all the visible files and folders to a new folder, I made a new .gitignore, a new git init, and a new heroku create. Now the main folder was only about 150MB, and when I wanted to push the project to heroku it was only 49MB.
So if you have the same problem I had check the weight of your files, maybe you have big hidden files. And it solved the problem to me.
Adding the following to gitconfig fixed this issue for me:
git config http.postBuffer 524288000
This allows for larger files to be pushed to a given repo. (I thinkš¤)
I'm on a Windows 8 Machine with git version 1.9.5.msysgit.0 pushing to a TFS Git Repository hosted on HTTPS.
When I push any text file everything is fine. But pushing a certain .jpg file git hangs on POST git-recieve-pack with the following output:
$ git push -v
Pushing to https://tfs.ourcompanyn.com/tfs/DefaultCollection/Prototypes/_git/TestProject
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 59.76 KiB | 0 bytes/s, done.
Total 5 (delta 3), reused 0 (delta 0)
POST git-receive-pack (61329 bytes)
It stays like this and does not change anymore
We use wincred as credentialhelper and I've checked that authentication works. Also I can push code. Just some of the .jpeg Files create this problem.
Is CMYK / RGB a problem? Is https with git and tfs a problem?
EDIT:
I've tried so far to increase http.postbuffer as mentioned in this post.
git config http.postBuffer 524288000
The problem occurs with msysgit and curl in the current version. There's a problem with handling authentication over HTTPS:
Documented here:
https://github.com/msysgit/git/issues/349
Solution:
Install the pre-release of Git for Windows 2.x
UPDATE:
Version 2.5.1 for Windows is released, so please use that one.
https://git-scm.com/download/win
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