gitlib
Jeff Anderson
I have a project I'm working on that gitlib would be very useful for.
I'm still not super sure about this particular licensing issue- gitlib
is distributed as part of smug, yet I would like to redistribute *just*
gitlib. As far as the GPLv3 is concerned, is this a problem to split the
library out from the smug project for redistribution?
Thanks!
Jeff Anderson
Andrew McNabb
No, you're fine. I think you just have to keep the copyright notices.
By the way, please send back any bug fixes you can.
Thanks!
--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
Jeff Anderson
> On Tue, Feb 17, 2009 at 07:21:59AM -0700, Jeff Anderson wrote:
>
>> I have a project I'm working on that gitlib would be very useful for.
>> I'm still not super sure about this particular licensing issue- gitlib
>> is distributed as part of smug, yet I would like to redistribute *just*
>> gitlib. As far as the GPLv3 is concerned, is this a problem to split the
>> library out from the smug project for redistribution?
>>
>
> No, you're fine. I think you just have to keep the copyright notices.
> By the way, please send back any bug fixes you can.
>
commit, and then a push. Yes, it must be a push. Is this functionality
out of the scope of gitlib? All I'm going to do is use subprocess to run
"git push" which is what I figure gitlib would do anyway, so I'm just as
happy to implement it in gitlib instead of in the rest of my project code.
Thanks!
Jeff Anderson
Andrew McNabb
> Sounds good. My project will actually require a local repo to take a
> commit, and then a push. Yes, it must be a push. Is this functionality
> out of the scope of gitlib? All I'm going to do is use subprocess to run
> "git push" which is what I figure gitlib would do anyway, so I'm just as
> happy to implement it in gitlib instead of in the rest of my project
> code.
If you're really only doing a "git commit" and a "git push", you might
find that using a library like gitlib is more overhead than it's worth.
Creating a subprocess only takes about two lines of code. Gitlib is
most useful where you need to read and manipulate objects in the
repository. For example, it lets you do commits in a bare repository.
If you have a working tree, and if you don't need to do concurrent
commits, then I'd probably recommend just using subprocess.
Jeff Anderson
> On Tue, Feb 17, 2009 at 07:44:56AM -0700, Jeff Anderson wrote:
>
>> Sounds good. My project will actually require a local repo to take a
>> commit, and then a push. Yes, it must be a push. Is this functionality
>> out of the scope of gitlib? All I'm going to do is use subprocess to run
>> "git push" which is what I figure gitlib would do anyway, so I'm just as
>> happy to implement it in gitlib instead of in the rest of my project
>> code.
>>
>
> If you're really only doing a "git commit" and a "git push", you might
> find that using a library like gitlib is more overhead than it's worth.
> Creating a subprocess only takes about two lines of code. Gitlib is
> most useful where you need to read and manipulate objects in the
> repository. For example, it lets you do commits in a bare repository.
> If you have a working tree, and if you don't need to do concurrent
> commits, then I'd probably recommend just using subprocess.
>
Hopefully some context will give some perspective. Basically what I'm
trying to do is automate the configuration of gitosis. An existing
Django site with a user base wants to host git repositories securely.
Gitosis allows this to happen without giving out shell accounts.
The configuration of gitosis is to clone the gitosis-admin repository
for a particular installation, update the gitosis.conf, and add any new
public SSH keys to a directory. You commit, and when you push the
post-receive hook updates the .ssh/authorized_keys file, and puts a copy
of the latest gitosis.conf in the appropriate place.
My idea here is to pull the public ssh keys from a Django-auth user
profile, update the gitosis.conf based on information held in a Django
model, commit these to a repository and execute the push. The push must
happen, and must happen over ssh (or sudo -H) because the post-receive
hook has to run as the gitosis user.
I considered reading the gitosis.conf file directly instead of
re-generating it from a model, but that can get hairy. I figure
generating from a model, and putting a big "do not modify this file"
notice in the gitosis.conf is the "safer" way to go for most setups.
That being said, gitlib seemed like a good choice when I was going to be
loading the gitosis.conf from the repo, and writing a new one out to the
repo.
After thinking through it again, I agree that it does seem like a bit of
overkill to use gitlib when I could just write the file out to a working
directory, and use subprocess to commit and push.
Thanks!
Jeff Anderson
Andrew McNabb
>
> My idea here is to pull the public ssh keys from a Django-auth user
> profile, update the gitosis.conf based on information held in a Django
> model, commit these to a repository and execute the push. The push must
> happen, and must happen over ssh (or sudo -H) because the post-receive
> hook has to run as the gitosis user.
Hmm. Does this update process happen manually, or is it automatically
run from within Django? If it's the latter, you'll have problems if
multiple people are doing this at the same time (and you'll probably
want to use gitlib to deal with this).
Pushing might get a bit hairy. It might actually be easier to
read/write from a bare repository and then get the other side to pull
it.
Jeff Anderson
> On Tue, Feb 17, 2009 at 08:58:41AM -0700, Jeff Anderson wrote:
>
>> My idea here is to pull the public ssh keys from a Django-auth user
>> profile, update the gitosis.conf based on information held in a Django
>> model, commit these to a repository and execute the push. The push must
>> happen, and must happen over ssh (or sudo -H) because the post-receive
>> hook has to run as the gitosis user.
>>
>
> Hmm. Does this update process happen manually, or is it automatically
> run from within Django? If it's the latter, you'll have problems if
> multiple people are doing this at the same time (and you'll probably
> want to use gitlib to deal with this).
>
be locked, gitlib might be the way to do this.
As for the pushing, one of the configuration options I am setting up is
the path to a private key that is allowed to push. If more security is
wanted, the gitosis authorized_keys file can restrict this key to only
be allowed from localhost. This way, the git push can be done in a
relatively safe manner. If localhost is compromised, there are much
worse things one could do than to push to a gitosis-admin repo.
I'll probably go ahead and use gitlib to address the clbuttic
multiple-people-at-the-same-time problem.
Thanks for the input!
Jeff Anderson
Andrew McNabb
> I never thought about the multiple-people issue. If a git repository
> can be locked, gitlib might be the way to do this.
Gitlib will let you do concurrent edits on a bare repository without
problems. But if you try to just run "git commit" in a non-bare
repository, you'll have bad luck.
> As for the pushing, one of the configuration options I am setting up is
> the path to a private key that is allowed to push. If more security is
> wanted, the gitosis authorized_keys file can restrict this key to only
> be allowed from localhost. This way, the git push can be done in a
> relatively safe manner. If localhost is compromised, there are much
> worse things one could do than to push to a gitosis-admin repo.
>
> I'll probably go ahead and use gitlib to address the clbuttic
> multiple-people-at-the-same-time problem.
Fun stuff. :)