<div dir="ltr"><div><div>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.<br><br>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).<br><br></div>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.<br><br>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.<br><br></div><div>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.<br></div><div><br></div>Generally speaking the automatic repacking that git does seems to be sufficient.  I haven't really noticed any issues with it.<br><div><br>-Matt<br><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 8:35 AM, matthew sporleder <span dir="ltr"><<a href="mailto:msporleder@gmail.com" target="_blank">msporleder@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am currently testing a NetBSD project conversion to git and am<br>
interested if anyone can share internals of the DFBSD git setup.<br>
<br>
Are you using gitolite and a common repo?  Or vanilla ssh+git?<br>
<br>
What is the most common workflow that's being employed?<br>
<br>
Any security and performance concerns you've already addressed that<br>
would be helpful?<br>
<br>
How often do you do things like repack?<br>
<br>
etc<br>
<br>
I appreciate any help,<br>
Matt<br>
</blockquote></div><br></div>