Tag Info

New answers tagged

1

YES, Usually corporate networks are behind proxy. Try to find your git repo server public IP (google it), ping it. If it isn't working you are probably behind a proxy server. If you are behind proxy use: git config --global http.proxy http://proxy_address:proxy_port git clone http://.../.. You can find proxy address in internet explorer ...


1

I often use an external, browser based, dns/ip lookup tool, like GetIP, to get the ip address of a server I'm trying to connect to. Then you can use the address for git, svn, etc as long as it's not explicitly blocked by your corporate firewall or proxy.


1

I have resolved this. The problem was the public key for the problematic server had already been added as a "deploy key" to Gitlab for earlier unrelated testing. It was then deleted as a deploy key, but for some reason the key persisted in the Gitlab DB. Gitlab then let me re-add the same key to a test user without complaining that it already existed ...


4

Yes, your whole code will be stored on their server. If someone compromises those services or steals your password/keys, they have access to the code (including all historical changes you made). If this is not acceptable because your company does not want their code to leave their offices, then you need to run your own git server in house.


0

This issue is caused due to incorrect configuration of ssh keys Every user should create a key and public key, i.e. /home/<user>/.ssh/id_rsa Every user should add the public key /home/<user>/.ssh/id_rsa.pub to the ssh section of GitLab If a user pushes to gitlab using git push origin <branch> a password prompt ...


1

You should take a look at git hooks. You can have a git hook on the server that is executed when code is pushed to it. My guess is that any output you do in these hooks is relayed to the client per default (not 100% sure though).


1

Apart from using the post-hook you should make sure that the your hook file is executable. So take a look at the file permissions make sure that you have chmoded the file to a+x. chmod a+x post-receive post-receive hook should be executable by git. If its not executable then git doesn't inform you. Also, make sure the first line is #!/bin/sh Hope this ...


0

Important note if your Windows is not in US English: the "users" group's name is locale-dependant. If your Windows is in Spanish, you'll have to change the files' ownership with chown $USER:Usuarios *


0

If all users have shell accounts with write access to the repository, you won't be able to set up a trustworthy audit log: they could still modify the repository without writing to the log, and they could write whatever they want to the log. To be able to trust the audit log, you would need to prevent direct file-level write access to the repository, ...


3

You can just pull it from GitHub on your servers, e.g. with a cron job.



Top 50 recent answers are included