Hot answers tagged git-repository
While the hook is running, GIT_DIR and (if the worktree was defined explicitly) GIT_WORK_TREE are set. That means your pull won't run with the second repository in the directory you changed to. Try git --git-dir ~/websites/testing/.git --work-tree ~/websites/testing pull; or unset git's repo-local environment with this: unset $(git rev-parse ...
Are you trying to compare the two tools from a system admin's perceptive or as a programmer? If you are looking at this from a programmers perspective perhaps you should ask this on stackoverflow. Or even better, perhaps you should look at what is already been asked about "git svn". http://stackoverflow.com/questions/871/why-is-git-better-than-subversion ...
There is no right or wrong answer here, except the one dictated by your own personal religion and the contents of the hier(7) manpage on your system. typical Linux hier manpage ; typical BSD hier manpage) /var/git/* seems reasonable to me personally. That's where I keep mine.
These days there is a "smart HTTP" upload feature, might even supersede the SSH access. No more private key generating is required, and installing should be easier, because the server component can be written in any language of choice: Running a Git server with IIS 7 and .NET 4: ...
I think it's worthwhile to examine the terminology used in git a bit here: git working tree: the files you're currently working on git staging area: files you indicate you want in your next commit git repository: a directory on your machine with the working files as well as a .git directory, which contains the complete version & branch history, etc. ...
Place it in a directory (or shared filesystem) under /srv. This is what it's for. The /srv directory is intended for site-specific data served by the system. From the standard: This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for ...
What OS is your server? It's a lot easier with a linux server. You can do it as follows (presuming you already have ssh access). I shall call your server sally, and your desktop dan, for convenience. Connect to your server from your desktop: ssh sally then on the server, create somewhere to keep your repos: mkdir -p /var/git cd /var/git Now you have ...
I would recommend gitosis gitosis aims to make hosting git repos easier and safer. It manages multiple repositories under one user account, using SSH keys to identify users. End users do not need shell accounts on the server, they will talk to one shared account that will not let them run arbitrary commands.
The primary repo would be under the SmallDevTeam account, and that account would add each developer's account as a 'private contributor'. Check out Episode 1 of the "Insider Guide to GitHub". It explains how to set this up at about the 24:30 mark: http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github
I would definitely advice gitolite. We use gitosis in house, manage a bunch of repositories that are about 20G in size compressed and have a lot of developers accessing them 24/7. The server usage is very light, never had an issue. Gitolite only improves upon gitosis and provides much finer grain of access control. I think we would be moving in that ...
I don't think either branching or forking is going to solve the problem for you. I believe you need to approach this from a completely different angle. The code that is shared between the sites is effectively a code library, and should therefore reside in a common library folder. In a LAMP environment, that would be /usr/share/php/. The individual sites ...
Out of the box, the standard git-daemon does not allow you to push into repositories. The man page says: This is ideally suited for read-only updates, i.e., pulling from git repositories. If you really want to enable anonymous push (and really, you don't; just use ssh), you need to enable the receive-pack service, which is disabled by default (because ...
The answer is the first sentence of the second link you have posted: "Gitosis stores repositories in the git user's home directory." If you have followed the tutorial from the third link you've posted, you should have created user git on your system, and Gitosis should be creating new repositories in the home directory of this user as long as you run ...
Since git is distributed by nature this seems to be pretty straitforward. For example the following scenario is possible: a team works with a local repo in the office performing pulls and pushes as if it was a central repo and a cron script pushes from that repo to the "real" central repo. If there are other developers a dedicated person will have to perform ...
When you set an environment variable, its only available within that shell--so when you launch another program, such as git, the local variables won't get passed along. Lets say we have test.sh: #!/usr/bin/bash echo "GIT_DIR=$GIT_DIR" Now lets look at the following examples $ GIT_DIR=LOOK_MY_GIT_DIR_IS_SET $ ./test.sh GIT_DIR= This is because the ...
Well, this might be technically possible, but it's not the idea behind the staging area. The point of the staging area is to control what you want to commit, for cases where you do not want to commit everything you changed in your working tree. Maybe you changed several different things in your tree, and want to commit only some of them, or you want to ...
There aren't really any pros to subversion over git, really. While git is distributed, everyone can work off of a central repository using remote tracking branches. git is faster, more flexible, and merging actually works. Plus, you can realistically work offline whereas with subversion, you cannot commit changes if you don't have You can work more ...
You may want to look into a deployment tool like Capistrano or Fabric. You can set up rules to exclude (or synchronize) certain directories. Alternatively, you could just use plain git.
As mentioned in the sources of gitolite install: Simplest use, if $HOME/bin exists and is in $PATH, is: git clone git://github.com/sitaramc/gitolite gitolite/install -ln So make sure your $HOME/bin exists and is in $PATH.
git-shell's man page has some information on using git-shell-commands. You can try adding a link in their git-shell-commands directory to passwd. ln -s /path/to/passwd ~user/git-shell-commands/passwd Then you can have them run git shell -c passwd and change their passwords themselves.
It says on the top: You already have a public ssh key on your local machine you can use that to initialize the repository. Don't have one? Look here. The linked article is great, should be no problem to follow it.
Try to use full path for target directory. For exampple: git clone ssh://root@serverIP/mysite/.git /home/user_name/mysite UPD: When git clones repo it creates directory for it based on repo's name. git clone email@example.com:username/repo.git Git will create directory repo. But there is NO repo name in your case mysite/.git.
Like voretaq7 said. Yes, it is highly advisable. In GitMagic ch3 there is a good explanation of why you want to use a bare repo. A bare repository is so named because it has no working directory; it only contains files that are normally hidden away in the .git subdirectory. In other words, it maintains the history of a project, and never holds a ...
An easy (inelegant?) thing to do would be: git clone --bare whatever ~/.git The --bare option tells it to basically checkout the contents of a normal .git directory (so it won't check out a working copy), and put into the directory ~/.git. You can use git checkout <file> to get individual files, or git reset --hard to replace all your existing ...
cd ~ git init git remote add origin ssh://host/repo.git git pull origin master this works for this situation. from http://stackoverflow.com/questions/9443927/git-clone-into-home-directory
Git works a littlebit different from SVN. I don't know how deep you are into Git but in short you don't need much work to get your Git repo to the server. The only thing Git needs is a SSH connection to your server. No deamon needed (at least for the Git hosting). Just to make it clear. In the Git philosophy every one who works on a project in Git has hiw ...
Sparkle Share – Git server installation in Ubuntu 10.04 I am starting with an empty Ubuntu server 10.04 with just openssh installed. I assuming that you can access you server from http://mydomain.com Install Git aptitude build-dep git-core apt-get install git-core git --version #(not necessary just to insure that is installed) Add user git adduser ...
Another option is to use SubGit $ subgit install /data/svn/repo/ The difference is that is also converts ignores, tags, EOLs-related settings, and the Git created is automatically kept in sync with the SVN repository. To break synchronization run $ subgit uninstall /data/svn/repo The resulting repository will br
Are you sure you are setting GIT_DIR properly? I assume you are pulling from a non-bare repo in that case your GIT_DIR should be GIT_DIR=/home/user/test_repo/.git To test this run the following on the command line: GIT_DIR=/home/user/test_repo/.git git status
Only top voted, non community-wiki answers of a minimum length are eligible