Tag Info

New answers tagged

-2

Found this link, and although it was helpful my blog entry might help clarify it: https://prestongarrison.com/change-port-git-is-using-for-ssh/ Basically i think its much better to just edit your .git/config file and make the changes.


3

You could do it with a git server-side hook (such as post-receive) that deploys your code. Gitlab CI is designed for this, however, and you should consider using it. If you go with a hook, the hook will be a shell script in .git/hooks/post-receive/. It will need deployment credentials and you will need to write it yourself. However, that is one use case ...


0

I have found the problem! During execution of the hook, the variables GIT_DIR and GIT_WORK_TREE are set, and git will ignore the current directory. And it seems that I can pass the directories explicitly to git: git --git-dir /path/git/me/.git --work-tree /path/git/me/ reset --hard Everything works now!


0

Well, as it turns out, the refused machine was behind a company firewall. I've asked the IT to exclude my gitlab server and that solved the problem Hope this info will help others in the future


0

You're missing the fact that hooks run on the local repo, and do not transfer between repos. So, the post-receive hook you've got in your repo only runs when your repo receives something, not when the remote repo receives something. In the case of Github, specifically, you can't setup "traditional" hooks, because Github doesn't want to be stuck running ...


0

This is where POSIX ACLs come in: setfacl -m g:www-data:rX -R /some/directory setfacl -m d:g:www-data:rX -R /some/directory The setfacl manpage will tell you exactly what's going on, but essentially the first command just sets an ACL for the www-data group to be able to read all files, and read+execute all directories, under /some/directory. The second ...


0

The typical approach to mirroring Git repositories is to implement a post-receive hook which pushes the new refs to the mirror repo. Things on Github will be a little trickier, because you don't have direct access to the hooks there -- instead, you'll need to use a Github "webhook" to notify an external service that the push has taken place, and cause a ...


0

As @EEAA mentioned in a comment, you almost certainly want a CI/CD system, not a chain of git repos. I've most recently been investigating go.cd, and it has nice support for the kind of "approval-based" deployments you're describing, via a web interface rather than needing people to pull/push code around. I'm a strong believer (as someone who does ...


1

For a small number of repos, the groups approach works just fine. Yes, each repo potentially needs its own group, and it does get unwieldy if you've got more repos. As @AlexeyTen mentioned in the comments, if you have a larger number of repos, or would like a more "high-level" management interface, you should look at a repo manager like gitolite or gitlab. ...


0

You can use a pre-commit hook to "warn" a user that they're committing with the wrong details, but there's no guarantee it will be run -- hooks aren't enabled by default on new clones (so people have to set them up themselves) and you can pass --no-verify to git commit to stop the pre-commit hook from running. It's a nice thing to provide, and recommend, so ...


0

uploadpack.allowReachableSHA1InWant from Git 2.5 allows it. Sample usage: mkdir server cd server git init touch 1 git add 1 git commit -m 1 git clone ./ ../local for i in {2..4}; do touch "$i" git add "$i" git commit -m "$i" done # Before last commit. SHA3="$(git log --format='%H' --skip=1 -n1)" # Last commit. SHA4="$(git log --format='%H' ...


0

Sounds like you're actually sharing the same working repo across multiple users, which is in general not a good idea: you're opening up to conflicts in the repo control - the errors could very well indicate such conflict, the file renaming would simply mask it but I guess changeset loss or even serious corruptions may happen especially if different ...


1

From git-clone(1): GIT URLS ... The following syntaxes may be used with them: o ssh://[user@]host.xz[:port]/path/to/repo.git/ ... An alternative scp-like syntax may also be used with the ssh protocol: o [user@]host.xz:path/to/repo.git/ The scp-like syntax doesn't have any way to specify an alternate port. scp supports ...


1

The answer to your question is no, there is no way within ssh to enforce regular changing pass phrases. As you're using a single account presumably all the public keys will be in a single authorised_keys file so you could invalidate keys by removing them from it. This though feels like too much effort and people could just use the same pass phrase on a ...


1

Building from source is quite straightforward. Digital Ocean has a nice guide on building Git from source on CentOS 7. Place the resulting binary in /usr/local/bin/ on your CentOS 7 system (which, by default, is included in your $PATH) and you're good to go. Of course you would prefer packages/using the repo, however given your situation I would not ...



Top 50 recent answers are included