Support for non-bare repositories (for git-svn origins)
os
it looks like I found a minor problem which could be fixed easily.
I have few gitolite repositories including some which are read-only
SVN clones (to keep an eye on SVN repos which are not ours). And I use
git svn rebase by cron for them. The problem is that git-svn doesn't
work with bare repositories, and thus the .git subdirectory is one
level deeper than for bare one. As a result, gitolite updates hooks
which are on the upper level, that is, not in the .git directory but
in the source directory which usually doesn't contain hooks subdir.
git push for gitolite-admin informs that it cannot symlink gitolite-
hooked for those repositories, but post-update hook dies and doesn't
update public keys, for instance, if I added new one.
I solved the problem temporary by adding empty hooks subdirectory to
the root of the source tree for such svn-cloned repos, and then
gitolite works (assuming that real .git/hooks/ dir also exists and
there are gitolites hooks in it).
But it would be good if gitolite can detect such non-bare
repositories. Or maybe there is another recommended configuration for
such cases. I tried gitosis first, and it seems that it didn't have
such problem.
Ralf Hemmecke
> SVN clones (to keep an eye on SVN repos which are not ours). And I use
> git svn rebase by cron for them. The problem is that git-svn doesn't
> work with bare repositories, and thus the .git subdirectory is one
> level deeper than for bare one. As a result, gitolite updates hooks
> which are on the upper level, that is, not in the .git directory but
> in the source directory which usually doesn't contain hooks subdir.
> But it would be good if gitolite can detect such non-bare
> repositories. Or maybe there is another recommended configuration for
> such cases. I tried gitosis first, and it seems that it didn't have
> such problem.
I also watch svn repos with git svn, but instead of cron, I trigger "git
svn rebase" by some svn update hook (which sends out a mail to me, which
in turn triggers my script).
In fact, my setup is then that the git svn clone lives in some
"autosync" dir. My script then does also a "git push" to a (bare) repo
that is controlled by gitolite. So basically, the script is the only
person that is allowed write access. Once you have this, I am sure you
know how you can handle the rest with gitolite.
So the simple trick is: use one (non-bare) repo for git svn and a bare
repo for gitolite. I don't think that harddisk space is a big issue, or
is it?
Ralf
Sitaram Chamarty
> Hi,
>
> it looks like I found a minor problem which could be fixed easily.
I'm sorry but right from the subject line, even without reading the
email, I can tell you I will not be supporting this. Server-side
repos are supposed to be bare, and I don't see why that needs to be
compromised. I notice that Ralf had another solution for you in a
later email; I hope you will use that.
> I solved the problem temporary by adding empty hooks subdirectory to
> the root of the source tree for such svn-cloned repos, and then
> gitolite works (assuming that real .git/hooks/ dir also exists and
> there are gitolites hooks in it).
I find no basis for that assumption. Which means in turn that
branch-level authentication may not work any more.
> But it would be good if gitolite can detect such non-bare
> repositories. Or maybe there is another recommended configuration for
> such cases. I tried gitosis first, and it seems that it didn't have
> such problem.
Sure, but gitosis doesn't have branch-level access control, so it
doesn't put any hook in *each* repo, only a "post-update" hook in the
admin repo.
--
Sitaram
Sitaram Chamarty
> branch-level authentication may not work any more.
damn typo... branch-level authorisation (or access control).
Obviously not *authentication* <sigh>
os
wanted to avoid it if possible, but without hacks it seems to be the
only way for now.
Regarding authorization, in my scenario, of course, it is not supposed
to have write access at all, so it is not a problem. But in general I
guess how non-bare repository can break gitolite logic. The only
difference is the location of git data, I guess.
Anyway, thanks to all for answers. I thought that I missed something,
but if it is 'by design', no more questions :-)
Serge van Ginderachter
I have few gitolite repositories including some which are read-only
SVN clones (to keep an eye on SVN repos which are not ours). And I use
git svn rebase by cron for them.