In the Repository Administrator section of the Everyday Git document it shows 
how to allocate accounts to developers so that you can have fine grained 
control over access to the repository (I assume it is because of that.  
Otherwise I assume you would do what I have done, and that is create a "git" 
user, with a home directory where you want to locate your repositories and 
then tell your users to put the following sort of entry in .git/remotes/xxx

URL:git@host.com:repository.git

and in ~git/.ssh/authorized_keys putting all the developers public keys.

).  But the example shows creating independant home directories for each of 
the developers - but then limiting their access by giving them git-shell as 
their shell.

I assume they would then user a .git/remotes entry of the form
URL:host.com:/absolute/path/to/repositories

My question, in this case is there any reason (such as git creating home 
directoriy temp files or something) why each developer could not have their 
home directory as the root of all the repositories (ie where my git user in 
the above example had its home directory).

This would then mean each user (unless he had a real account on that machine) 
would then use the following in .git/remotes

URL:host.com:repository.git

Which has the advantage of not revealing exactly where on your filesystem you 
have chosen to store the repository (or more precisely allowing you to move 
it without all users having to change their.git/remotes urls)


-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
-

No reason why not.

I use my home directory for all _my_ projects, and just clone them within 
my own network with

	git pull g5:v2.6/linux ..

rather than using the absolute path-name.

And no, git should never use your home directory for anything else (ie 
all file operations are normally done just in $GIT_OBJECT_DIR or 
similar: some things like "git-diff-files" will use the current working 
directory, but nothing uses $HOME (*)).

So I would indeed suggest that the home directory would be the natural 
place to put developer projects.

		Linus

(*) Not entirely true. "git-cvsimport" uses "$HOME/.cvspass" for CVS 
passwords. But the _basic_ git commands shouldn't do that.
-

Do you mean to reuse single directory /home/gitu/ for user A, B, C,
and hang repositories /home/gitu/{X,Y,Z} for projects?  I'd
imagine things could be arranged that way.  User A and B but not
C may be in "projectX" group and /home/gitu/X is writable only
by projectX group members and such...

-

That would work from a _git_ angle, but I don't think that was what Alan 
was talking about, and it would failr horribly from a "ssh" perspective 
(because "ssh" will want $HOME/.ssh/authorized_keys etc).

So I _think_ what Alan was describing was just a 

	/home/user-A/project.git
		     another-project.git
		     ya-project.git
	      user-B/myproject.git
	      user-C/..

setup, and then people can always just describe their own projects by just 
doing "git pull host:<projectname>", without ever caring _where_ their 
home directory is.

(And yes, "git pull user@host:project" also obviously works fine, in case 
your user name at the hosting site isn't the same as the user name on your 
local site).

However, to be truly useful for this kind of hosting schenario, 
"git-shell" still needs to be extended to be able to at a minimum create 
(and delete) projects.

It probably also makes a lot of sense to be able to pre-populate a 
project, so that you don't have to do a remote "git push" to push a big 
project over the network, when another version of that project already 
exists at the hosting site.

			Linus
-

Actually Junio was right in layout - but I am not sure he understands what I 
want to achieve.

What I have in mind is that I am a personal developer at home with my own 
server.  I have written various code in a number of projects whose public 
repositories are all located under /var/lib/git. 
(ie /var/lib/git/projectA.git, /var/lib/git/projectB.git) and they are all 
shareable.

git-daemon is run with base-path as /var/lib/git and have defined user "git" 
to have a home directory of /var/lib/git and git-shell as his shell, so 
anyone can clone from them

So, if my projects take off, and I have some outside developers helping me, I 
do not want to give them individual home directories on my server instead my 
plan_had_ been to collect their public keys at put them 
in /var/lib/git/.ssh/authorized_keys, and then tell them to push to the 
repository via

URL:git@home.chandlerfamily.org.uk:projectA.git

etc.

The downside of this approach is that all developers get access to all 
repositories - maybe I need better control.


Then I saw the howto on repository control with the update hook and was 
thinking that I could do it as follows

in /etc/password create an entry for each developer with a home directory 
of /var/lib/git and git shell. (so I DO NOT create a large number of /home 
directories at all) and make them members of group git.

Then each developer would access the repository via

URL:home.chandlerfamily.org.uk:projectx.git

but would be only allowed access if they were on a white list within each 
project.

Thats when I asked the question that started this thread.  

Since then I have realised that the downside of this is that its pretty easy 
to fake being someone else and getting access by just giving someone elses 
name.

So the third approach I am now contemplating is to actually create separate 
users for each project

so user projectA had a home directory of /var/lib/git/projectA.git with a 
subdirectory of .ssh for the authorized keys file.

...
[ message continues ]

This is the part I highly doubt is doable -- without having
separate unix level UID your whitelist mechanism would not work.
And I do not think you would get separate unix level UID without
having separate $HOME/.ssh directory, even if you have prepared
separate unix level UID in your /etc/passwd file.

Come to think of it, it is worse than that.  IIRC, sshd has
rather strict check to make sure that only one unix user can
write into $HOME/.ssh/ directory (obviously the owner of that
$HOME directory, which means the user who has the directory as
her home directory in /etc/passwd).  If more than one unix level
user shares a home directory, I do not think you can satisfy
that checking.

Maybe it does not matter, since they will be pushing the commits
with their name set to committer/author fields and if you trust
them, but then there is no point assigning one UID per user.

One UID per project is probably doable but I do not think that

You still cannot distinguish your users in a project with each
other, which may or may not matter to you.  Also this is
inconvenient for your developer who works on more than one of
your projects -- I think he needs to use one project identity
for each.

So in short, I am mildly negative about this.  If I were doing
this kind of thing I'd have one unix UID and one directory per
one physical user.  What is the real reason (other than "I just
do not want to" feeling) you want to have smaller number of home
directories than you have users?


-

On Thursday 02 February 2006 05:44, Junio C Hamano wrote:

You are right.  I don't know whether you can tell, but I wrote my last note at 
just gone 5:00am my time this moring  after getting up to go an catch a 
flight to Germany for the day.  I spent the flight and the wait for the 
flight back going over the options in my mind and I NOW think it better to 
have proper home directories.

I do have to say, my motivation originally was more about not announcing to 
the world the internal structure of my filesystem rather than the limitation 
around creating lots of home directories, but part of the reasoning to myself 
today was that that probably doesn't really matter.

-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
-

Hmph.  I thought that was what Alan was talking about, after he
read about the shared repository configuration section that
mentions git-shell, which is about shared repository.

Project administrator or project secretary sets up the shared
repository for the project and member accounts on that machine,
and members just use that shared repository.  Not allowing
remote repository creation nor deletion over git-shell is a

Hosting is a different story and I think branch/tag removal in
addition to repository creation, and deletion you listed above
are needed in that context.  Your "my projects are all under my
HOME directory, it is very convenient and things naturally work"
would apply for non-shared (i.e. something each person can call
"my") repositories, and would apply to hosting situation, of

Depends on what you mean by pre-populate, but that may just mean
to be able to manage objects/info/alternates remotely.
Capability to manage hook scripts may also be needed to a
certain degree if the repository side access control (e.g. who
can push into this branch) is done by hooks/pre-update, but in
either the hosting environment or a shared project setup, the
machine owner who is paranoid to install git-shell would want to
control what hooks can do very carefully.  The operator would
probably not allow updating of hooks at all, but install a BCP
hook by Carl Baldwin.  The users can only manage what is in the
info/allowed-{users,groups} file.

What this implies is extending what git-shell allows is a
concious policy decision and probably be quite different from
site to site until a set of BCP emerges.

-

you cannot tell a person using one key to become "git" on that
machine from another person using different key to become the
same "git" on that machine; if you do not care about that
then it is OK.  That would work only when all of your git
repositories are supposed to be accessible by everybody.

But I suspect doing so would not let you have different projects
with different subset of "git" users on your shared machine.

-