dfbsd git setup

Matthew Dillon dillon at backplane.com
Thu Jan 29 12:25:47 PST 2015


Vanilla ssh+git with a dedicated master repo machine with most developer
accounts set to git-only (using command= restrictions in
.ssh/authorized_keys).  So there is no direct login access to the master
repo machine except for the ~3 people that maintain it.

Users and other third parties do not pull directly from the master repo.
There is a 2-minute cron job on the main distribution machine (another
dedicated box) which pulls from the master repo machine and makes the repo
available publically via the git:// protocol.  After that it fans out with
mirrors and anyone else who wants it pulling from the main distribution
machine.  Users too, since incremental updates are relatively cheap.
Nearly always using the git:// protocol since it guarantees consistency
(things don't get out of synch like they can with CVS).

For developers the workflow depends on how big a project is being worked
on.  For small things the developer typically just pulls and pushes
directly to the master repo box.  For larger projects that might need
collaboration the developer pulls from the master repo box into their local
git repo on our developer box (or their own box if they want).  This
per-developer local git repo is publically available via git:// so the
developer then advertises the existence of their working branch and other
people can pull and mess with it, usually into their own local (publically
available) git repos.  The main developer can then accept patches or pull
changes back from the other developers repos into their own.

Once the project is deemed ready the main developer usually rebases and
pushes it to the master repo and everyone resyncs to the master repo.
Usually the developer shouldn't rebase while their mini project is going on
because rebasing messes up anyone trying to pull from their local repo.
It's a last step before pushing them back to the main repo.

This is the real power of git, the ease of which developers can make local
branches available to others from their own copies of the repo without
garbaging up the main repo with weird branches, for anyone to be able to
pull the work, mess with it in their own local repo however they like, and
so forth.

Generally speaking the automatic repacking that git does seems to be
sufficient.  I haven't really noticed any issues with it.

-Matt



On Thu, Jan 29, 2015 at 8:35 AM, matthew sporleder <msporleder at gmail.com>
wrote:

> I am currently testing a NetBSD project conversion to git and am
> interested if anyone can share internals of the DFBSD git setup.
>
> Are you using gitolite and a common repo?  Or vanilla ssh+git?
>
> What is the most common workflow that's being employed?
>
> Any security and performance concerns you've already addressed that
> would be helpful?
>
> How often do you do things like repack?
>
> etc
>
> I appreciate any help,
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20150129/f9f9b0bb/attachment-0001.htm>


More information about the Users mailing list