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: ...
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 ...
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. ...
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 ...
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 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.
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 ...
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 ...
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 ...
Github has just launched a set of new pages describing how to use Github for this scenario. http://dotfiles.github.com/
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 ...
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 ...
Use git filter-branch. An example from the manpage: git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD
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 ...
Looks like I was able to create it like this: git push origin BRANCH_NAME
Figured it out... I needed an extra / after file:// so that it started at the root of the filesystem. Darn it! Final command worked: git svn clone -s file:///data/svn/repo/ /data/git/repo.git
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 ...
Just push through SSH; setup your remote as MyServer:/path/to/gitrepo and away you go. If you want to provide read-only access to the Internet at large, you can either use HTTP, or git-daemon to support git:// protocol URLs.
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.
Git uses templates to set up new repositories. I don't know if Gitorious uses these same templates, but it's worth checking out. On my system they exist at /usr/local/share/git-core/templates/hooks.
The book Pro Git has a whole chapter on providing Git services: Git on the Server. It also covers gitosis and gitolite.
Why not just add their public keys to the gitosis server? Or have them use dedicated keys for gitosis that they have installed on both S1 and H1? Then there's nothing more to install.
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.
Only top voted, non community-wiki answers of a minimum length are eligible