I am using gitolite v2.2 on Ubuntu 12.04.
The GL_REPO variable does not get expanded for emailprefix.
In my gitolite.conf file I have this:
repo #all
config hooks.mailinglist = xxx#somewhere
config hooks.emailprefix = "[%GL_REPO] "
config hooks.emailmaxlines = 1000
...
repo testing
RW+ = #all
I am getting email when I push changes to the testing repo, but the subject line looks like this:
[%GL_REPO] branch master updated.
Is there a typo in my configuration, a setting I missed, or is this a problem in v2.2?
The substitution of the variable GL_REPO in gitolite.conf file is only documented in gitolite v3 (or 'g3') pages:
Admin conf
"git-config" keys and values
the conf/gitolite.conf file
For g2 (gitolite V2.x), it is only mentioned (and expanded) for gitolite hooks.
Upgrading to v3 is therefore the way to go, since it won't affect any of your existing bare repos: see the migration page.
Related
I'm trying to set up RStudio with gitlab. I have never used gitlab before, so i'm following set up instructions found online.
I created my gitlab account and project without any issues. I then followed the instructions found here for connecting RStudio with gitlab:
https://www.enricodata.com/post/setup-gitlab-with-rstudio/
The instructions say:
"In Rstudio go to Terminal and paste the following:
git config - - global user.email “YOUR EMAIL”
git config - - global user.name “YOUR NAME”
git config remote.origin.url git#gitlab.com:Allerious/code project.git"
When i execute the first two lines of code it outputs this in the console:
I'm unsure if this means it has done what it's supposed to have done.
Note: I did change “YOUR EMAIL” and “YOUR NAME” when running the code.
When i execute the third line of code it outputs this:
I'm thinking i should be changing the directory path to something else, but i'm unsure how to do this and what it should be changed to.
Here's another screen shot:
Maybe i should be changing the directory to one of these?
I've got an account with OpenShift which provides a git repository for each project you to work in. I've got one main project and two smaller projects resulting in a total of 3 git repositories.
I have just started to use the two smaller projects in the main project and seen that git can use the submodule command. I've added them both to the custom directory like so:
git submodule add ssh://...#app.rhcloud.com/~/git/app.git/
git submodule add ssh://...#api.rhcloud.com/~/git/api.git/
which has produced a directory structure like so:
node_modules
custom
app ------ full of tasty files
api ------ full of tasty files
index.js
.gitmodules
Within the .gitmodules file I have
[submodule "custom/api"]
path = custom/api
url = ssh://...#api.rhcloud.com/~/git/api.git/
[submodule "custom/app"]
path = custom/app
url = ssh://...#app.rhcloud.com/~/git/app.git/
Which is exactly what I want. It all works locally.
git add --all
git commit -m "new submodules"
git push
The issue is when I run the git push, it comes back with this error:
remote: Host key verification failed.
remote: fatal: Could not read from remote repository.
remote:
remote: Please make sure you have the correct access rights
remote: and the repository exists.
It looks like I need to add the ssh key of the main project to the two smaller projects so that I can ssh. Does anyone know how I can do this or have a better way of including submodules in OpenShift?
Thanks for the help in advance.
It looks like I need to add the ssh key of the main project to the two smaller projects so that I can ssh
At the parent (main) repo level, this shouldn't be the case: all the push does is to push the .gitmodules, and 2 gitlinks (special entries in the index) representing those 2 submodules.
It is more likely that the push doesn't find the proper .ssh/known_hosts, or the public/private ssh keys in order to push back to the app.rhcloud.com upstream repo: See "SSH connection problem with “Host key verification failed…” error" and "The authenticity of host can't be established".
I'm on a fresh install of Linux Mint.
I'm getting the following error when trying to push from any repository:
error: Malformed value for push.default: simple
error: Must be one of nothing, matching, tracking or current.
fatal: bad config file line 8 in /home/leng/.gitconfig
fatal: Could not read from remote repository.
This is very odd, because I definitely have a version that supports the simple push behavior.
The output of git --version is git version 1.8.3.2.
The contents of ~/.gitconfig:
[user]
name = My Name
email = MyEmail#website.com
[color]
ui = true
[push]
default = simple
Here's where it gets creepy.
If I change the behavior to matching (or to nothing, tracking, or current, for that matter), then attempt to push, I get the same exact error message. How is that possible? Is it caching the config somehow? I've even tried rebooting. I've even tried purging GIT completely from the system (and deleting ~/.gitconfig) then reinstalling it.
If I delete the [push] section completely from the .gitconfig file (or if I delete the file entirely), then try to push, then I get this:
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)
error: Malformed value for push.default: simple
error: Must be one of nothing, matching, tracking or current.
fatal: bad config file line 8 in /home/leng/.gitconfig
fatal: Could not read from remote repository.
...so it appears to be both acknowledging that I haven't chosen a pushing behavior, but then also saying that I've chosen an unsupported behavior. What on earth is going on here?
I even get the error if I delete ~/.gitconfig completely.
Can anyone help me out with this witchcraft?
Thanks!
EDIT:
Here is a .git/config file requested:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://{my remote repo}
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Okay, so I fixed it, but the method is absolute witchcraft.
I tried to isolate the problem by purging GIT, deleting the config file, reinstalling GIT, then creating a local bare repository, then cloning it, then attempting to push from there. Pretty much like this:
sudo apt-get purge git-core
rm -f ~/.gitconfig
sudo apt-get install git-core
cd /git
mkdir foo
cd foo
git init --bare
cd /var/www
git clone /git/foo
cd foo
touch blah.txt
git add -A
git config --global user.name "Name"
git config --global user.email "user#email.com"
git commit -m "Blah"
git push
...same exact error message, no change there. (Still some serious witchcraft.)
Then, I deleted one of my repositories that doesn't have a local origin (it connects to its origin via SSH) and cloned the repository anew after deleting it (with a fresh git clone ssh://... command).
I got an error from the clone command:
remote: Malformed value for push.default: simple
remote: Must be one of nothing, matching, tracking or current.
Ah ha! Now it says remote instead of error. So the remote doesn't support this behavior. (That doesn't explain why the error persists on local-only repositories with local origins, then, though.)
So I then SSH'ed into the remote server and updated the git-core there to the latest version, re-attempted to clone the repository from my local machine, and it worked.
Now, I can finally git push. Insanely, this also fixed it so I can git push from the entirely local /var/www/foo to the also entirely local /git/foo (the local origin bare repository). SSH'ing into this remote server and updating it somehow - WITCHCRAFT - fixed my local machine's error.
Why on earth the entirely local repos care about an entirely different machine's GIT version is... beyond me. How utterly, utterly insane.
I had the same error message on git push.
For me it turned out that the remote user's git was an older version (1.7.2.5),
and I had recently updated the remote ~/.gitconfig to include:
[push]
default = simple
The solution was to remove this setting from the remote's configuration.
Since it seems other people are having this issue, and I found a solution HERE, I thought I'd post the solution that worked for me.
IN SHORT:
The solution I found was at this page. Evidently the best solution is to upgrade to a newer version of Git (if possible). That was not an option for me, however. From a local machine, I typed the following command:
git config -–global push.default upstream
This got rid of the Malformed value for push.default: simple error I had been getting. I'm not entirely sure what upstream does, however.
MY CONTEXT (for comparison): I had an empty (bare) repository on a remote computer, and I had a few repositories on a couple "local" workstations. I pull from the remote repository, do some work, and then push my work to the remote repository. Pushing/pulling was accomplished via SSH. Most of the time, while working on a local machine, pushing/pulling would result in the error described above.
In short, before the fix, I had the following ~/.gitconfig file on the remote machine:
[user]
name = Foo Bar
email = FooBarPerson#email.com
[diff]
external = /Users/foobar/bin/git-diff-cmd.sh
[color]
diff = auto
status = auto
branch = auto
[push]
default = simple
After entering in the above command, my ~/.gitconfig file on the remote machine changed to:
[user]
name = Foo Bar
email = FooBarPerson#email.com
[diff]
external = /Users/foobar/bin/git-diff-cmd.sh
[color]
diff = auto
status = auto
branch = auto
[push]
default = upstream
Version information:
Remote machine (repository location): 1.9.4
My laptop: 1.8.5.2 (Apple Git-48)
Other computer I work on: 1.7.7.4
Here's another site that may be useful to some people:
http://www.lorrin.org/blog/2011/10/03/argumentless-git-pull-and-git-push/comment-page-1/
I'm wondering is there a simple way to install hooks for certain repo using gitolite_admin.
Let's imagine i want to have post-update hook for repo awesome using gitolite_admin repo cloned to my workstation...
#conf/gitolite_conf
repo awesome
RW+ = deployer
contents of post-update:
#!/bin/sh
echo "Post receive-hook => updating Redmine repository"
sudo -u deployer perl -we '`cd /home/deployer/repo/awesome.git && git fetch -q --all`'
You could also look at "repo-specific environment variables"
A special form of the option syntax can be used to set repo-specific environment variables that are visible to gitolite triggers and any git hooks you may install.
For example, let's say you installed a post-update hook that initiates a CI job. By default, of course, this hook will be active for all gitolite-managed repos. However, you only want it to run for some specific repos, say r1, r2, and r4.
To do that, first add this to the gitolite.conf:
repo r1 r2 r4
option ENV.CI = 1
This creates an environment variable called GL_OPTION_CI with the value 1, before any trigger or hook is invoked.
Note: option names must start with ENV., followed by a sequence of characters composed of alphas, numbers, and the underscore character.
Now the hook running the CI job can easily decide what to do:
# exit if $GL_OPTION_CI is not set
[ -z $GL_OPTION_CI ] && exit
... rest of CI job code as before ...
Of course you can also do the opposite; i.e. decide that the listed repos should not run the CI job but all other repos should:
repo #all
option ENV.CI = 1
repo r1 r2 r4
option ENV.CI = ""
That feature is fairly recent (started in commit 999f9cd39, but in this case, completed in commit 63865a16 June 2013 for 3.5.2).
But even you don't have that version, there are other ways to do this using option variables, as the last part of that section explains.
Before this feature was added, you could still do this, by using the gitolite git-config command inside the hook code to test for options and configs set for the repo, like:
if gitolite git-config -q reponame gitolite-options.option-name
then
...
And you can use git config variables in the same way.
Or you can use group membership -- see the comments against function "in_group" in "Easy.pm" for details.
# in_group()
# return true if $ENV{GL_USER} is set and is in the given group
# shell equivalent
# if gitolite list-memberships $GL_USER | grep -x $GROUPNAME >/dev/null; then ...
In addition to sitaram's answer, the recent (August 29th, 2013) commit 62fb31755a formerly introduce repo specific hooks:
it's basically just creating a symlink in <repo.git>/hooks pointing to some file inside $rc{LOCAL_CODE}/hooks/repo-specific (except the gitolite-admin repo)
You cannot specific a hook for gitolite-admin though.
And you hook is only one of the three following authorized hooks:
pre-receive
post-receive
post-update
That means you can:
store your repo specific hooks in your gitolite-admin/hooks/repo-specific/xx
declare those your in the gitolite-admin local options on the server.
First enable those hooks:
ENABLE => [
# allow repo-specific hooks to be added
# 'repo-specific-hooks',
Then declare the hooks on the server gitolite-admin repo:
gitolite git-config gitolite-options.hook=reponame hookname scriptname
(with a tab or \t between reponame hookname scriptname)
Original answer:
As mention in the gitolite man page on hooks
if you want to install a hook in only a few specific repositories, do it directly on the server.
(otherwise, you would be managing hooks for all git repos through gitolite-admin/common/hooks)
That being said, you could take advantage of VREF in gitolite V3.x, which are update hooks: those can be set for some repos and for some user, like any other rule.
You could then:
make your VREF script leave a 'flag' (a file) in the appropriate bare git repo being updated
make a common 'deploy' post-update hook, which would first look for that flag, and if found, deploy the repo (and remove the flag).
Again:
a post-update hook managed through gitolite-admin can only be common to all git repos (not what you want)
only VREFs can be associated to repos and users through gitolite.conf
The solution above tries to take those two facts into account to achieve what you are looking for: a deploy script running only for certain repos and managed through the gitolite.conf config file of the gitolite-admin repo.
Here are step by step instructions to complement #VonC's answer
gitolite hook for specific repository
In my gitolite.conf file I've added a bunch of config gitweb.description lines but I dont see the changes when I view gitweb. If I look in the repos on the server the description hasn't been updated.
How do I get them to sync up?
Normally, the update happens on pushing that gitolite-admin repo back to the gitolite server, through triggers.
You can manually trigger them on the server to see if that makes any difference:
gitolite trigger POST_COMPILE
Make sure the description is within a repo section:
repo myrepo
config gitweb.description = some description
Double check the content of the projects.list file, and that your GIT_HTTP_BACKEND is well set.