On Fri, 27 Sep 2013 00:29:47 -0700 (PDT)
Fabien Bourigault <dra...@gmail.com> wrote:
> I'm moving my projects from svn.
>
> With svn I use ssh and a svnserve wrapper like this one :
>
> #!/bin/sh
> umask 002
> exec /usr/bin/svnserve "$@" -r /very/long/path/to/projets
>
> So I can use URI like this one : svn co
> svn+ssh://m...@my-server.com/my-super-project/trunk
>
> How can I achieve the same behavior with git (i.e. something like git
> clone m...@my-server.com:my-super-project) ?
Nothing different if you're okay with having real system Unix accounts
for your developer on a target system. The only problem is short
pathnames of projects but I'll show ways to deal with it after
explaining the basic setup.
The main premise to make things work is that your Git-repositories
should be group-shared. Git has support for this, but for convenience
you'd better off helping it to do its part of the work properly.
1) Install Git. There's no special "server-side Git" binary if you
intend to access your repositories using SSH [*], so just install
Git like `apt-get install git`.
2) Make sure all your system accounts for Git developers are members
of a single special group -- be it "devel" or "git", -- it doesn't
matter. Suppose we've picked "git" for this.
3) Create a central place for your repositories.
On a typical GNU/Linux system conforming to FHS, I'd recommend
to create the "/srv/git" directory (you already have "/srv")
and make it belong to root:git and have access rights 2755
(or 2750 if you're paranoid), that is, group writable with group
sticky bit set on.
4) For each of your project, create a *bare, shared* repository by
running something like this:
# cd /srv/git
# umask 002
# git init --bare --shared project1.git
Verify that the created project directory and its files have sensible
access rights -- the "--shared" option which is short for
"--shared=group" ensures the directory is group-writable and has
group sticky bit set on it, and the step (3) should have made the
directory's owning group to be "git".
5) Now try to push something to is from a client:
git remote add origin ssh://m...@my-server.com/srv/git/project1.git
git push origin master
You can now see that you can't easily drop the leading part of the
project's directory pathname from the remote repository's URL because
there's no layer of indirection when accessing Git repositories via
SSH: the client Git process just spawns another Git process on the
remote machine after setting up an SSH channel, and hands it off the
pathname. The only supported shortcut is ~ with the expected meaning.
I'd say that is not really a problem because:
1) Most of the time you're working with named remotes, so you only
have to type in the URL once.
2) If the repositories are located in a somewhat standardized place
(/srv/git), the leading pathname part is not a big deal to type.
Anyway, there's another approach which is a layer of indirection
between you and Git. These days, a low-level de-facto standard tool for
this is gitolite [1]. It provides *virtualized* Git users (so that you
only have one system account to access Git repositories, and still each
developer has their own SSH key), repository- and branch-level access
controls, and more. And as a by-product, since it requires all the
repositories be located under a single directory, and it knows which
one, it provides for short-cut syntax, like
ssh://me@my-server/myproject
[*] There's a special Git daemon, unsurprisingly called git-daemon,
which is able to serve Git repositories: unauthenticated
and hence read-only (but you can turn certain knobs to make
it serve R/W as well--in certain controlled environments this
might be OK to do). This daemon works kind of like svnserve in
that it allows to specify a base directory for the projects
using its "--base-path" command-line option.
1. https://github.com/sitaramc/gitolite
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
