I setup a git server on Debian and created a folder called git in /srv/git/.
Inside the folder, I'd like to divide my git projects by cloud hosted cloud and on-prem hosted on-prem. Inside of these two folders contain the hostname and it's specific files needed for deployment, redeployment, etc.
So a server that does apache on the cloud with a hostname like webapp will have a folder structure like /srv/git/repos/cloud/webapp.
Should the command git init be ran from the cloud folder or webapp folder?
I presume your setting up the bare repo.
As you mentioned in the question, you want to have separate git projects plural here so what I understood is you want to have more than one project under cloud directory.
Method 1:
cloud
|------->webapp
|------->something1
|------->something2
Very straight way is doing /srv/git/repos/cloud/webapp.git here webapp is the git repo.
Setting up the webapp as git repo.
git init --bare /srv/git/repos/cloud/webapp.git
--bare: for the bare repo you can skip this using on exisiting repo.
Though init is not harmful to give on existing repository is safe. It will not overwrite things that are already there
Method 2:
cloud (git repo)
|------->webapp (submodule)
|------->something1 (submodule)
|------->something2 (submodule)
In another option where you can keep cloud as git repo and make webapp as submodule. That is repo inside the git repo.
You can choose what fits to you best.
I suggest to use two different repo, if your have plenty of submodules in one git repo it might be cumbersome at the start to keep track of things.
The answer to your question is that you should run git init from the cloud folder, giving webapp as the first argument, i.e. git init webapp.
That said, you could also create the webapp directory, change into it, and then run git: mkdir webapp; cd webapp; git init; The end result will be exactly the same, but why bother?.
Related
I have a VPS running a Node.js / React app.
I want to update the files in the vps each time I push data to the git(hub).
I found out, using this answer, that I can add some hooks in git, executing commands on "post-receive".
What I didn't quite understand :
Why did he init another git ? Couldn't he have done this in the .git directory and create the hooks/post-receive file?
Why git checkout -f ? If the goal is to update local files, so nodemon / create-react-app restarts the server / app, why not execute a git pull instead ?
Is there a better way of doing this ?
In the recommended answer there, nobody is using GitHub and there is no other Git repository yet. So the answer to your question:
Couldn't he have done this in the .git directory and create the hooks/post-receive file?
is: No, there was no .git directory in the first place. The target machine had nothing at all, no Git repository, no working tree, etc. The git init --bare created the Git repository (the ".git directory").
The git checkout -f is a poor-man's / low-quality implementation of push to deploy. A receiving repository is normally "bare", and this one is no exception.
why not execute a git pull instead ?
That would require creating a third Git repository. That would have been an option.
"Better" is in the eye of the beholder. There are many ways of doing this, each with its own pluses and minuses. See also Deploy a project using Git push, which notes that since Git 2.3, receive.denyCurrentBranch = updateInstead is available; it was not available prior to 2015 (and in 2015, many people had older versions of Git installed).
Note further that if you're using GitHub as a hosting system, this changes a number of variables. The questions and answers you and I have linked here are aimed at those not using GitHub.
We use the google git-repo tool (aosp repo) to manage a workspace of many git repositories. However, if you want to do a clean checkout that is exactly the same as the last workspace, using the command repo sync will pull in all the changes from remotes first.
How can you get the local repositories populated from only the local cache that is currently in the .repo/ directory?
You can use:
repo sync --local-only
From repo help:
$ repo help sync
[...]
-l, --local-only only update working tree, don't fetch
Due to my old installation of Gitlab being too difficult to upgrade (Thread on TKL support forums: http://www.turnkeylinux.org/forum/support/20120913/upgrading-gitlab ), I have downloaded the current TKL Gitlab distro, and followed Gitlabs standard upgrade path so that I now have a fully upgraded Gitlab 6.1 installation running with TKLBAM and all that good stuff. So far so good.
But, it turns out that our old version of gitlab does not give HTTP urls to repos, so that means that I can't use the "Import existing repository" function in Gitlab 6.1
I know that i can simply copy the old Git repositories from the old VM to the new one, but how can I make these repositories visible in Gitlab on the new VM?
I recently migrated from gitolite to gitlab and the official rake task gitlab:import:repos worked for me. I am using gitlab 6.1.0 (82f3446). Here is what I did:
rsync bare repos from gitolite to repositories/{group}/. Make sure to replace {repository} with the name of the gitolite repo, and change the hostname of your gitlab server.
rsync -rth --progress repositories/{repository}.git \
git#gitlab-server:/home/git/repositories/{group}/
Here, {group} is the name of the user group you want the repository to be added to. If you don't have any specific group, choose root as the group name.
Fix permissions – only necessary when the rsync user is not git:
sudo chown -R git:git repositories/{group}/
cd ~/gitlab
Run the rake task to import all new repositories:
bundle exec rake gitlab:import:repos RAILS_ENV=production
Now if you login as Administrator you will find the new project added.
For more information, refer to the "Import bare repositories into GitLab project instance" under http://{your-gitlab-server}/help/raketasks.
In your case, you can login to your old TKL system and rsync all bare repos to the new instance, followed by an import.
One option would be to:
Clone the old repo from gitlab onto a dev machine.
Create a blank repo on the new gitlab.
Add the new repo as a remote on the dev machine.
Push everything back to the new repo.
Remove the old repo from remote repos list.
To create a remote called newRepo, do: git remote add newRepo gitlab.localhost.com:User/newRepo.git (replace the url on the end with the one for your repo)
I did it practically the following way after reading ChrisA answer, which gave me a little headache about how to do it practically. The example copies a repo from github to gitlab, to make source and destination a little bit clearer.
Clone the old repo from github onto a dev machine (which creates a bare repo):
$ git clone --mirror git#github.com:me/myrepo.git
Create a blank repo on the new gitlab.
Add the new repo as a remote on the dev machine.
$ cd myrepo.git
$ git remote add newRepo git#gitlab.com:me/myrepo.git
Push everything back to the new repo.
$ git push --mirror newRepo
That's it.
This way it copied all branches and tags to the new destination.
You can now remove the cloned bare repo from your dev machine.
If your Gitlab is >= 8.9, then you can use export/import to migrate repos.
Since GitLab 13.8 (January 2021), you now have:
Migrate Groups directly between instances
A faster and easier way to migrate your GitLab Groups is on the way.
Group Migration is a new feature that lets you copy a GitLab Group from one instance to another directly, without having to export and import any files.
In this release, we migrate only the Group object with basic fields.
We plan to follow up with more and more fields and related objects until all relevant data in a Group is migrated in this easy-to-use fashion.
See Documentation and Epic.
So I have been plagued with this weird git problem that myself and a few other developers have not been able to solve. Here it is:
I created a bare repo for managing website changes using git on test server.
For this example the repo is here: /home/website/website.git
The website public root would be here: /home/website
I created the repo by doing this command: git init --bare
inside the git repo directory "website.git"
Next I have my local repo on a machine elsewhere. This is a standard git repo. I build the site get it ready to deploy. When its ready I push it to the bare repo. From my local repo.
There is a post-receive hook that checks the latest file tree out into the public root of the website. So when I change things on the local repo and test them in the localhost environment, once satisfied I can push them to the live server.
Here is the problem I face:
I can push fine. No issues. All works as expected. Code gets checked out to public root. Everybody is happy and goes on with their life.
BUT!!!:
The site is a CMS site. Users log in to it and upload things. Files get created on the public root of the website which is the GIT_WORK_TREE.
So NBD right?! I can just commit the files every now and then from the live bare repo and pull them back to my local environment like I have before. So I log into SSH on the server. Navigate to /home/website/website.git
Then run this command:
GIT_WORK_TREE=/home/website/ git add ../
I get this mess:
error: unable to create temporary sha1 filename ./objects/cb: No such file or directory
error: error_log: failed to insert into database
error: unable to index file error_log
fatal: adding files failed
I have done this before on other servers and it worked fine from what I remember. So I was like WTF, must be something strange on this server. I went to another server I have and replicated the EXACT same steps. Got the EXACT same problem. So now I fear I am loosing my sanity and maybe these previous git experiences are all made up in my head.... *Well, lets not go that far yet.... :)
Maybe somebody can help me out here. I have used git plenty and can't seem to crack this one.
Oh, some other maybe useful specs:
running CENTOS 6.2
I double checked all permissions. I even tried changing everything to 777 recursively just to make sure Im not loosing it somehow. Made sure all the files are owned by the correct user. chowned recursively. I also tried the standard solution to this problem which is described here: https://answers.atlassian.com/questions/132671/git-commit-fails-with-sourcetree-error-unable-to-create-temporary-sha1-filename-git-objects-d8-file-exists
That didnt work either. Not sure where to go from here.
PLEASE HELP ME!!!!
I feel like Linus is playing cruel tricks on me right now.
You have a bare git repository in /home/website/website.git which is inside of a git repository in /home/website? And then you try to trick the bare git repository into having a working tree using GIT_WORK_TREE?
Maybe it is worth understanding this setup but only if you intend to be a git developer. As you are a user focused on delivering website functionality, I suggest using a standard git setup.
Move the bare git repository elsewhere:
$ mkdir /home/repo
$ mv /home/website/website.git /home/repo/website.git
$ cd /home/website
$ git remote set-url origin /home/repo/website.git
I got the solution. This is it. I was running the above command from the git repo.
Turns out the command should be run from the work tree and altered to look like this:
GIT_WORK_TREE=/home/website/ git --git-dir="./website.git/" add ./
I am fairly new to Git. I have worked locally, but today i need to setup a remote machine with the git. I have no idea how.
Basically my setup is like this.
I have a windows machine which has a vmware player installed, which is used to connect to the dev ubuntu linux machine where out Git repo is situated. I putty to the dev machine and do all the operation related to git with username common to all the developers username : dev
Now there is a new rollup that is created in the dev git repo which is required to be deployed on our ubuntu linux test server. I have my account in test server. username:ash.
What are the steps that should be followed to setup this. I have some time back had a discussion with one of my colleague who had shared about using SSH key. As he is the only contact person who is not available, I have no info how to proceed. I have created the SSH key.
login to the machine as "ash".
ash#gitserver:~$
create a new directory that will contain the git-repository
ash#gitserver:~$ mkdir rollout.git
change into the directory
ash#gitserver:~$ cd rollout.git
initialize the git repository
ash#gitserver:~/rollout.git$ git init --bare
go back to your dev machine and clone the newly created repository or add it to the "remote"s of an existing git repo. use "ssh://ash#gitserver/~/rollout.git" as the remote-url.
[update for cloning]: make sure that there is not already a "rollout" directory in the directory where you want to clone to. for simplicity, create an empty directory "foo/" and try to clone into that directory. you can then move the cloned repository to wherever you want to.
push changes to the new repository.......done!
the use of ssh-keys will make authentication simpler and/or more secure but is in no ways necessary (or related) to setting up the git repository.