"Sean Kelley" <sean.v.kelley@xxxxxxxxx> writes: > One other question - how do you rename a branch on the remote > repository once you have created it? Right now, there is no way to remove a ref, so even "create new and then remove" would not work. You need a way to ssh-in to the machine and run "branch -d" there. You would need an access to run git tools on the remote site for: - repository creation and deletion - ref deletion - fsck, pruning and repacking - adding entries to objects/info/alternates - managing hook scripts with the current set of tools, which pretty much means an account with a full shell access over SSH. Earlier in another thread, Linus said that it is justifiable to treat repository creation as a special event and outside of git. For one thing you need to have the account on the site and arrange access permissions and authentication before you can create a repository, so it is an understandable position to take, and for people with full SSH access it is a minor nuisance that they have to first go there to perform the above operations instead of running "git-do-things-at-remote host:path" locally. However, for sites that want to restrict the access via git-shell, after a repository owner secured such an account and access rights, not being able to allow the user to do some of the above things himself is a burden on site administrators. This _could_ be improved by allowing some common operations via git-shell. Even under git-shell, the process'es user and group credentials are the primary means to control the access rights. So in that sense, letting the user to say things like the following might make sense: $ REPO=repo.example.com:/pub/scm/git/project.git $ git remote-admin $REPO create-repository $ git remote-admin $REPO delete-repository $ git remote-admin $REPO repack $ git remote-admin $REPO fsck-objects $ git remote-admin $REPO count-objects And for the sake of both simplicity (which would lead to security) and to allow the site administrator to make policy decision, I think we do not have to (and we shouldn't) make the above commands to take any flags. The command's availability and what parameters to be passed to underlying commands such as git-repack are determined by the site administrator. For example, an administrator may give a restricted account to a user _and_ set up one repository for him but may not want to give him rights to create another repository nor delete that initial repository given to him, in which case create-repository and delete-repository actions would be disabled. I have a feeling that the users should not be given full control over 'hook' scripts, but I am not sure. A site administator might want to forbid too expensive hooks from running, even the process spawned by the user would work only in directories that the user has access to. If we give the users a full control, then: $ git remote-admin $REPO get-hook $hookname >old-contents $ git remote-admin $REPO put-hook $hookname <new-contents $ git remote-admin $REPO remove-hook $hookname would be the set of commands we could use (I am assuming put-hook installs the hook in "enabled" state, and get-hook would give a failure for nonexistent or disabled hooks). The most straightforward extension of the above for ref deletion is to say: $ git remote-admin $REPO delete-refs refs/heads/foo refs/tags/v1.0 and that would be the simplest way to implement it if we were to go with "git remote-admin". However, I think people would find it more natural if manipulation of refs were part of "git push". "git push $REPO $src:$dst" means "take what I have in $src in my local repository, and update the $REPO's $dst ref with that". So as a natural extension of that, we could make: $ git push $REPO '':$dst to mean "store nothingness in $dst" and make that a way to express the desire to remove $dst ref. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html