I've just started using gitolite and I can't find a way to verify changes I've made to gitolite-admin repo, i.e. changes to configuration, before pushing. So what happens is that I make changes, commit and push only to learn that I've made a typo in the config file or a key file is missing. Nothing dramatic, but I end up with an ugly commit history, making it difficult to follow what was changed when. Is there a way around this?
You can either:
amend your last commit locally and force a push to the remote gitolite-admin repo
(git commit --amend, followed by a git push --force).
or have an intermediate staging gitolite server in which you wan review/approve the changes before pushing the the live gitolite server.
Honestly, for gitolite I have always used the first option.
Related
I've successfully (I think!) removed large files from a gitlab project mirrored on my local drive using BFG. I don't want to replace the existing gitlab project (for safety reasons), but instead want to push to a new test gitlab project. Here's the commands I've done successfully so far:
git clone --mirror git#git.domain.com:architecture-team/IOMobile.git
java -jar bfg.jar --strip-blobs-bigger-than 100M IOMobile.git/
cd IOMobile.git
git reflog expire --expire=now --all
git gc --prune=now --aggressive
Those commands seem to have done the trick, now how do I reset the origin to:
git#git.domain.com:architecture-team/testiomobile.git
...and then push the mirror into the new project? I'm not sure how to reset the origin on a mirror and want to make sure I don't change the original project.
Do I just do a simple
git push
or do I need
git push --mirror
Thanks for any help
-Owen
I think in this case it does not matter if you specify --mirror or not. Since you cloned it already with the --mirror flag, a normal git push will update all refs on the remote server. This is also described at the bfg docs: https://rtyley.github.io/bfg-repo-cleaner/
But there is a gotcha you could run into. If you see this error message while pushing:
remote: GitLab: You are not allowed to force push code to a protected branch on this project.
Then you have to enable Allow force push option in the GitLab project settings at URL https://git.domain.com/architecture-team/testiomobile/-/settings/repository
After the push you should disable the Allow force push again.
I am using git from a long time but never set it up on server. Refereeing to this Git: move existing repository from PC to server, clone from server
I have initiate a bare repo on server but while adding origin in local
"git remote add origin server:path/to/repo" i have no idea what to add here. My site is getwalkwel.com and user is getwamld
Thanks
Origin is the name of a remote which is typically created automatically when you clone a repo from another repo. The origin reference in the cloned repo will be created to point back to the repo that was cloned from.
In your case, where the bare repo was actually created later from your working repo, you will create origin in your working repo to point back to your new bare repo.
This is done with:
git remote add origin /barerepo/fullname
If your bare repo is going to line on a different machine, then you need the URL to reach the repo instead of just a file path.
For instance, you might have myuser#myserver:path/to/repo
Bare repository in Git is a repository which only contains version control information only in fact this will not have .git sub-directory or any working files.
This kind of repository is helpful when you need to share or divide your work between few people for example in work environment you and your team mates are working on same project and you all need to see changes and all needs to do push to repository in this case this repository is more useful.
You can add the remote repository to local git repo
$ git remote add origin ssh://myserver.com/var/git/myapp.git
pushing to remote repository:
to push our local master branch to the origin's master branch. You can do that using the git push <target> <local> command.
$ git push origin master
click here for more information on how this works
My git client is behind my git server by a couple revisions and a git push doesn't seem to work because I did something quirky:
I had a git server on a machine whose harddrive crashed. Luckily, I had a backup although the backup was a couple of months old. I then made a new server and placed the backup git files up on the server.
In the time between the crash, I had made changes to files and committed them to the server. I have, for example, 1.4.8.30 locally, but only 1.4.8.26 on the server. When I try to git push the changes to the master branch on the server, it thinks everything is up-to-date, even though I can see the server is behind.
How can I get these files up to the server? I am scared I am going to lose revisions, or that these two are not correctly synced now. Thanks!
With Git, you have the complete repository locally (in .git directory).
Therefore a "restore" procedure should be:
Create a new bare Git repo (on the server)
git init --bare new-one.git
change origin (on the client)
git remote rm origin
git remote add origin path-to-new-one.git
Push your local data to repo
git push --all
Note: This is gets more complicated if there are more than one users with different local commits. Hopefully, you do not need that ;)
I have got a gitolite v2 installed on my company's server, and now I have to administrate it. Since it's really chaotic there I decided to install a new one, now it's v3. I have around 8 repositories what I want to move to the new install.
I don't need the old .rc file or any configurations, just the (working!) $GIT_HOME/repositories/*.git
What I tried: (found it while searching for solution)
copied all $GIT_OLD_HOME/repositories/*.git to $GIT_HOME/repositories/*.git (except gitolite-admin.git and testing.git)
then I updated the gitolite-admin.git/conf/gitolite.conf (by cloning and pushing back changes) with this kind of entries:
repo myrepo1
RW+ = #all
Now if I want to clone anything other than gitolite-admin or testing, it sais:
FATAL: R any myrepo1 myusername DENIED by fallthru
Few things I've checked:
ls -l $GIT_HOME -> gitolite:gitolite it's ok I guess since gitolite is the user I want to use
I did the same for all entries in the repositories directory and the permissions are the same.
I was googling for a solution however I didn't find any that fits my case. If you can help me or suggest me anything, please don't hold back :)
If you need any more details to find out the answer just tell me.
I had the same problem and upgrading did not work as it should so I used the following strategy - the bold text represents where was the step executed:
1- New: Install Gitolite (https://github.com/sitaramc/gitolite).
2- Workstation: In a new empty directory clone the gitolite-admin of the old version and rename it to gitolite-admin-old. Remove access to all users in gitolite-admin-old/conf/gitolite.conf except yourself - To disable anyone to do any change while you are migrating the repositories.
3- Workstation: Clone all repositories from the old Gitolite. git clone git#oldserver.com:repo.
4- Old: We already got what we want from the old repository. Disable old gitolite for good by adding exit 0 at the top of .gitolite.rc file.
5- Workstation: Clone gitolite-admin from the new server git clone git#newserver.com:gitolite-admin gitolite-admin-new
6- Workstation: Copy keys from the gitolite-admin-old/keydir to the gitolite-admin-new/keydir, add the repositories you want to transfer in the new gitolite-admin-new/conf/gitolite.conf with the user priviledges. add, commit and push.
7- Workstation: Push each required repository to the new server
git push --all git#newserver.com:repo
git push --tags git#newserver.com:repo
or
git push --mirror git#newserver.com:repo
8- Workstations: Change DNS or remote URL from each working repo.
Hope this helps
Make sure you have migrated your .gitolite.rc file, as described in the g2->g3 migration page
if you're migrating from g2, there are some settings that MUST be dealt with before running gitolite setup; please read the migration page and linked pages, and especially the one on "presetting the rc file"
The rc file for g3 is quite different from that of g2.
Or if you don't need the old one, as you mention, make sure the content of the default new one has appropriate values.
Make sure your new ~git/.ssh/authorized_keys file does contain a line with myusername in it.
The OP Attila Horvath confirms:
Note: nothing in any of the gitolite install/setup/etc will ever touch the data in any repository except the gitolite-admin repo. The only thing it will normally touch in normal repos is the update hook."
The last sentence just grabbed my attention, and it seems now that was the problem.
I first installed gitolite then copied there the repos, so I had to run again gitolite setup -pk mykey.pub and now it seems working!
i am new to git and now i am trying to set up a git server and want to access the server from client.
referred many links but those are not helping me. i tried with the link http://davedevelopment.co.uk/2010/12/05/how-to-install-gitolite-on-ubuntu-10-10-maverick-meerkat.html. after the final step in the document i didn't know how to proceed.
can anyone give the details?
thanks in advance.
if you have cloned a repository on your client you are ready to start coding...
git commit
to commit changes locally, and
git push
to push your changes to the server.
What is missing on the above answers is how to push on the server a new repo.
Suppose that in the gitolite config file you have a repo named my_repo, you can add to the server an existing local repo this way:
cd my_repo
git remote add gitolite git#your.git.server:my_repo
git push gitolite master
You have to type ONLY ONCE the second line above. After that, you only have to push.