From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-143491-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 767801381F3
for <garchives@archives.gentoo.org>; Tue, 18 Dec 2012 02:01:08 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id A986B21C01C;
Tue, 18 Dec 2012 02:00:51 +0000 (UTC)
Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 8812F21C01B
for <gentoo-user@lists.gentoo.org>; Tue, 18 Dec 2012 01:59:36 +0000 (UTC)
Received: by mail-ea0-f169.google.com with SMTP id a12so25306eaa.28
for <gentoo-user@lists.gentoo.org>; Mon, 17 Dec 2012 17:59:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=+HCxIYWKdLHXDOj/j2mnq497Rmpdf65kzo9c7DVboyI=;
b=aB4MwpoD/n0/SHeRNr28+wYn6+cBzRy6QYSWjDmc9C1z1YHas+0eRIlHbjfpyS7tOQ
7mHLMmivA0hfYypvmksqFuqjrWQWaPAcXRR0Mn/HGpzfePGSzehJbPRGZQm4359cX754
ScepiTEmfEJCsqfTGCLQ1Wh+dhKjE2h0+rcUlicT3B6L0hfgeFEi0FIeEA6tKSMiPQu1
CE9amRa1Ly9atxhhcDinQQAUguM75tdGLEBLGAM27o7e6c7Kb+VfSY0k3HD6V/mAAd5S
Zx/cV+QLSqFQCDF5qdH9ya4JHfF9YNZCyTxOP2CVW6PiKsD4uk7mjfrIRckhk1xnxmfL
AOzw==
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.14.174.198 with SMTP id x46mr1107444eel.23.1355795974868; Mon,
17 Dec 2012 17:59:34 -0800 (PST)
Received: by 10.223.158.68 with HTTP; Mon, 17 Dec 2012 17:59:34 -0800 (PST)
In-Reply-To: <50CFC301.4090200@orlitzky.com>
References: <CAN0CFw1WninDPPk4PS85ojoXTP7D1=syDS7gfYYje9vEEUacwQ@mail.gmail.com>
<50CF44B4.2050107@orlitzky.com>
<CAN0CFw3fUnHR65MnkTFRNtPn4APHAQ-6iHnZ8XRH_AF5i5wpog@mail.gmail.com>
<50CFC301.4090200@orlitzky.com>
Date: Mon, 17 Dec 2012 17:59:34 -0800
Message-ID: <CAN0CFw2gHzD-bQR9hLiwgegWE7PQJQf_8W1UKsrqheBf3RcTSw@mail.gmail.com>
Subject: Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code
From: Grant <emailgrant@gmail.com>
To: Gentoo mailing list <gentoo-user@lists.gentoo.org>
Content-Type: multipart/alternative; boundary=047d7b62430a784ef104d116d9cb
X-Archives-Salt: 52501bb9-50bd-472f-88ce-b3cd7611d9bb
X-Archives-Hash: 6076586f8282767b9952620cd3ba9783
--047d7b62430a784ef104d116d9cb
Content-Type: text/plain; charset=ISO-8859-1
> >> If all you need to do is host git repositories, I suggest putting bare
> >> repos on a server somewhere and having everyone push/pull over SSH. You
> >> can use the bare-bones gitweb (comes with git in portage) to view the
> >> repos from a web browser. You'll need a separate bug tracking mechanism
> >> in that case.
> >
> > I haven't used git before at all. Is this pretty easy to set up?
> >
>
> If your users all have SSH access to some server, you don't have to do
> anything at all. Git works by pushing and pulling from other
> repositories. Those repos may reside on a friend's machine, or a server
> somewhere; conceptually, it doesn't matter[1].
>
> So, for example, I have a git repo for my reapply_default_acl project in
> ~/src. I can clone this somewhere else by doing,
>
> $ mkdir -p tmp/acl
> $ cd tmp/acl/
> $ git clone ~/src/reapply_default_acl
> Cloning into 'reapply_default_acl'...
> done.
>
> that easy. To do it over SSH is identical. I can connect to my own
> machine via SSH for another example:
>
> $ rm -rf reapply_default_acl
> $ $ git clone ssh://mjo@localhost:443/~/src/reapply_default_acl
> Cloning into 'reapply_default_acl'...
> Password:
> remote: Counting objects: 102, done.
> remote: Compressing objects: 100% (85/85), done.
> remote: Total 102 (delta 34), reused 3 (delta 0)
> Receiving objects: 100% (102/102), 33.86 KiB, done.
> Resolving deltas: 100% (34/34), done.
>
> That's all that's involved. You give people "commit access" by allowing
> them to write to the directory.
>
>
> [1] This is a slight lie. If you're going to have a centralized repo
> that you only push to, you'll want to do two things. First, create the
> server repo with `git init --bare` so that you don't have an extra copy
> of checked-out files lying around. Second, go into the 'hooks' folder of
> the server repo and rename the post-update.sample file to post-update.
Thank you for taking the time to explain this. You just sextupled my git
knowledge. It does sound easy. Would a basic layout like this plus gitweb
plus fugitive/gitv yield a git setup that wouldn't feel lacking for
collaboration amongst a few people? It sounds like a bug tracker would be
a good addition.
- Grant
--047d7b62430a784ef104d116d9cb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
> >> If all you need to do is host git repositories, I suggest put=
ting bare<br>> >> repos on a server somewhere and having everyone =
push/pull over SSH. You<br>> >> can use the bare-bones gitweb (com=
es with git in portage) to view the<br>
> >> repos from a web browser. You'll need a separate bug trac=
king mechanism<br>> >> in that case.<br>> ><br>> > I h=
aven't used git before at all. =A0Is this pretty easy to set up?<br>>=
; ><br>
><br>> If your users all have SSH access to some server, you don'=
t have to do<br>> anything at all. Git works by pushing and pulling from=
other<br>> repositories. Those repos may reside on a friend's machi=
ne, or a server<br>
> somewhere; conceptually, it doesn't matter[1].<br>><br>> So,=
for example, I have a git repo for my reapply_default_acl project in<br>&g=
t; ~/src. I can clone this somewhere else by doing,<br>><br>> =A0 $ m=
kdir -p tmp/acl<br>
> =A0 $ cd tmp/acl/<br>> =A0 $ git clone ~/src/reapply_default_acl<br=
>> =A0 Cloning into 'reapply_default_acl'...<br>> =A0 done.<b=
r>><br>> that easy. To do it over SSH is identical. I can connect to =
my own<br>
> machine via SSH for another example:<br>><br>> =A0 $ rm -rf reap=
ply_default_acl<br>> =A0 $ $ git clone ssh://mjo@localhost:443/~/src/rea=
pply_default_acl<br>> =A0 Cloning into 'reapply_default_acl'...<=
br>
> =A0 Password:<br>> =A0 remote: Counting objects: 102, done.<br>>=
=A0 remote: Compressing objects: 100% (85/85), done.<br>> =A0 remote: T=
otal 102 (delta 34), reused 3 (delta 0)<br>> =A0 Receiving objects: 100%=
(102/102), 33.86 KiB, done.<br>
> =A0 Resolving deltas: 100% (34/34), done.<br>><br>> That's a=
ll that's involved. You give people "commit access" by allowi=
ng<br>> them to write to the directory.<br>><br>><br>> [1] This=
is a slight lie. If you're going to have a centralized repo<br>
> that you only push to, you'll want to do two things. First, create=
the<br>> server repo with `git init --bare` so that you don't have =
an extra copy<br>> of checked-out files lying around. Second, go into th=
e 'hooks' folder of<br>
> the server repo and rename the post-update.sample file to post-update.=
<br><br><div>Thank you for taking the time to explain this. =A0You just sex=
tupled my git knowledge. =A0It does sound easy. =A0Would a basic layout lik=
e this plus gitweb plus fugitive/gitv yield a git setup that wouldn't f=
eel lacking for collaboration amongst a few people? =A0It sounds like a bug=
tracker would be a good addition.</div>
<div><br></div><div>- Grant</div>
--047d7b62430a784ef104d116d9cb--