My Gerrit replication.config looks like:
[remote "company-svc"]
projects = dev-portal-ui
url = git#gitlab.eng.company.com:/core-build/${name}.git
push = +refs/heads/*:refs/heads/*
I'm able to mirror clone using command:
cd ${GERRIT_SITE}/git
git clone --mirror ssh://git#gitlab.eng.company.com/core-build/dev-portal-ui.git
On Gitlab, I found ssh URL as:
git#gitlab.eng.company.com:core-build/dev-portal-ui.git
Is my configuration for replication.config is correct?
Yes, it is.
Both SSH URLs syntax are correct:
ssh://git#server/...
git#server:...
The first one is the SSH URI scheme, the second one is a scp-like syntax.
Related
I have a locally hosted version of bitbucket, and a github account. I want to be able to connect to both easily. I tried this .gitconfig version, does not work seamlessly. What Am I missing? What should I put under user in both systems?
#Github (default)
Host gh
HostName github.com
User ?
IdentityFile ~/.ssh/id.pub
#Bitbucket (secondary)
Host bb
HostName stash.company.com
User ?
IdentityFile ~/.ssh/id.pub
In your local repo, a "remote" is defined to tell git what repository to go to when doing things like push and pull.
The default name is "origin".
So we enter commands like "git pull origin main"
The command "git remote -v" will show the "remotes you have defined, like this:
git remote -v
origin git#github.com:/.git (fetch)
origin git#github.com:/.git (push)
You can define another remote to point to a different remote repo:
git remote add
So if you add a remote and call it bborigin then
git pull bborigin main
would pull the main branch on remote bborigin
(I do not know if you will need special steps to set up authentication on the different remotes)
First, you need to put that in ~/.ssh/config
That means you can:
test your authentication with ssh -Tv gh or ssh -Tv bb
use those Host entries in SSH URLs with
git clone gh:me/myGitHubRepository
git clone bb:me/myBitBucketRepository
Second, a typical global .gitconfig (in $HOME\.gitconfig) would look like:
[alias]
st = status
lg2 = log --graph --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(bold white)- %an%C(reset)' --abbrev-commit
lg = !"git lg2"
br = branch
[user]
name = You
email = your#email.com
[core]
autocrlf = false
safecrlf = false
commitGraph = true
quotepath = false
longpaths = true
[rebase]
autostash = true
autosquash = true
[pull]
rebase = true
[protocol]
version = 2
[gc]
writeCommitGraph = true
[credential "helperselector"]
selected = manager-core
[credential]
helper = manager-core
manager = manager-core
[init]
defaultBranch = main
This assumes you have downloaded and installed GCM (Git Credential Manager), the credential manager which helps caching your credentials (username/password) for HTTPS URL.
Not mandatory in your case, though, if you stick to SSH URLs.
After install gitolite in a GCP compute engine and added a new ssh public key in gitolite-admin/keydir/charley_rsa.pub and add a new repo for charley:
conf/gitolite.conf:
repo test
RW+ = charley
Then: git clone gitolite-admin in GCP local console is ok.
When we do git clone in remote local pc, it shows 'DENIED by fallthru' error
git clone ssh://git#serverip/test
Cloning into 'test'...
FATAL: R any test charley_rsa DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
( clone testing (#all) in remote local pc is ok )
finally, it's resolved after updating the public key filename
I used the id: charley in the conf file: gitolite.conf
repo test
RW+ = charley
after change the public ssh key filename
from "charley_rsa.pub" to "charley.pub"
ssh -i ~/.ssh/id_rsa git#serverip info
hello charley, this is git#serverip running gitolite3 v3.6.6-13-g8bde76d on git 1.8.3.1
R W gitolite-admin
R W test
R W testing
The way you add new keys is by first cloning gitolite_admin repo, modifying it and pushing back: that triggers the recompilation of the ~/.gitolite/ configuration files.
If you do anything directly on the server, then follow "administering gitolite directly on the server"
You would need at least
gitolite compile; gitolite trigger POST_COMPILE
I'm desperately trying to prepare a correct environment for a new project. We plan to work locally with Xampp with my team and then push everything on a testing server, so I've started to learn git and its specificities.
When I try to push everything is ok, but then I want my server to automatically pull the updated files where it was cloned. So I created a post-update file which is like this.
#!/bin/bash
echo "Mise en production..."
cd /home/test/public_html/
unset GET_DIR
git fetch origin master
The problem is I get this error
remote: Mise en production...
remote: fatal: Not a git repository: '.'
Is there a better solution that would be efficient ?
Thanks everyone.
Your attempted solution works, but you have overlooked one detail.
When changing into /home/test/public_html/, you need to realize that this directory is not a Git repository and hence, you cannot fetch into it. To make this work, execute the following once.
$ cd /home/test/public_html
$ git init
$ git remote add origin [path/to/git/repo]
After that, you'll be able to git fetch and git pull in /home/test/public_html.
The [path/to/git/repo] should be a relative or absolute path to the directory that contains your repository. This is the directory that has directories branches, hooks, info, et cetera.
It seems you need that after the local repo changes are pushed to a testing server, then you also want the local changes are pushed to your server. So you can use post-update hook to do that:
In the testing server, edit the contents of hooks/post-update file as below:
#!/bin/sh
echo "Mise en production..."
branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')
git push -u /path/for/your/server $branch
echo "push to my server "
I created a repo in gitlab and set the user.name in a global way.
When I try to push my project, after inserting my password, I get the following error:
fatal: 'user/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.
My .git/config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git#gitlab.domain.tld:user/test.git
fetch = +refs/heads/*:refs/remotes/origin/*
output from "git remote -v:
origin git#gitlab.domain.tld:user/test.git (fetch)
origin git#gitlab.domain.tld:user/test.git (push)
What could be the problem?
Try using this:
git push https://username:password#gitlab.com/user/test.git
I've seen some issues in the newer versions of git that give me trouble when I don't specify the username and password every time. I'm sure there's a way around it but I haven't figured it out yet. Git recommends rolling back to older versions, but I'm sure there is a less drastic way.
In Settings you want to add with
git push https://yourusername:yourpassword#gitlab.com/user/test.git
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/