Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle creation of new repositories #34

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Rogdham
Copy link

@Rogdham Rogdham commented Nov 16, 2014

This PR adds a new feature that allows for:

  • Perform some checks before creating a new repo;
  • Calling some command when a new repo is created.

Implementation

When you gitreceive init, a new script named newrepo is created next to the receiver script.

When a new repository is to be created, the newrepo script is called instead of simply creating a new repository.

Of course, the default of the newrepo script is to add a new repository as always, but it also takes a few other parameters that allow to neat uses of this feature, namely the name of the repository, the username and fingerprint of the user trying to create the repository.

Use cases

Performing some checks before creating a new repo.

This allow to control which user/fingerprint can create which repo. Or to inforce some policy on the repo names.

As an example, the following newrepo script will make sure that users can only create repo starting with their usernames followed by a dash (note that only the middle part has been edited from the default newrepo script):

#!/bin/bash
# This script gets called to create a new repository at $repo_path.
# Note: /dev/stdout is already redirected to /dev/null.
declare repo_path="$1" repo_name="$2" username="$3" fingerprint="$4"

# Check if $repo_name starts with $username-
if [ "${repo_name##"$username"-*}" ]; then
    echo "Error: your repos should start with '$username-'." > /dev/stderr
    exit 1
fi

# The default is to create a bare repository ($repo_path is absolute)
git init --bare "$repo_path" || exit $?

And here is the output when you try to git clone (the same happens if you git remote add and git push on an existing local repo):

$ git clone [email protected]:foobar
Cloning into 'foobar'...
Enter passphrase for key '<snip>': 
Error: your repos should start with 'alice-'.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.
$ git clone [email protected]:alice-foobar
Cloning into 'alice-foobar'...
Enter passphrase for key '<snip>': 
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

Calling some commands when a new repo is created

Just append those commands at the end of the newrepo script.

Please review

This is quite an important change, but I believe the feature could allow many use-cases, as it is quite flexible. For example, I put the git init --bare in the newrepo script to allow that to be changed if needed (however, make sure that a repo_path is been created).

Please note that if this PR is accepted, current gitreceive users should add a newrepo in their existing $GITHOMEs, since it is only created when you gitreceive init. This means that some communication may be needed.

Pleade do review this PR. I tried to stick to the coding conventions I saw, but feel free to mention any problems (e.g. if you don't like the name of the newrepo script).

Final note: I've put a new link to the wiki on the README, which would have to be populated when/if this PR is merged. The content of this PR can act as a good starting point for that.

Add script `newrepo` in $GITHOME, that allows for:
 - Perform some checks before creating a new repo
 - Calling some command when a new repo is created
@Rogdham
Copy link
Author

Rogdham commented Nov 20, 2014

On second thought, I am not really sure whether this PR is going in the way the gitreceive project should go. Even though I tried to make it small, it adds some complexity nonetheless.

First things first, I am not sure that creating a newrepo script is the best implementation. Maybe an environment variable? I'm not really sure.

The thing is that it would allow for permissions check on repo creation. If this PR is merged, then one would continue on that path, and add a scripts that gets triggered on git push as well, which would allow for permissions check on git push. And so on… At the end of the day, we would have something like gitolite, and probably not as convenient.

I would argue that the selling point of the gitreceive project is that it is simple and small. Missing some advanced feature is not necessary a big deal in that regard.

Please advise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant