<div dir="ltr"><div>I should add that when developers create their own branches in their own local repos, they usually also keep those branches up-to-date with the main repo (when convenient) by periodically merging master into them.  Developers resolve conflicts in their local repos before pushing anything back to the master repo.<br><br></div><div>Right now, for example, I have a 'wlan' branch in my local repo at <br></div><div>git://<a href="http://leaf.dragonflybsd.org/~dillon/dragonfly.git">leaf.dragonflybsd.org/~dillon/dragonfly.git</a> for our wlan update which we are resyncing with FreeBSD, at another developer is tracking that to help port the rest of the drivers.  It isn't ready to go into the master repo yet because various drivers are in a broken state.<br><br>And ftigeot, who is doing most of the gpu drm work uses local branches quite often when synchronizing against linux because doing so often causes a certain amount of instability which needs testing and fixing before we would want to throw it to the general user base.<br><br></div><div>And similarly for other work.  I think all told developers have a few dozen local branches going, sometimes for active projects, sometimes simply to save work that they have set aside.  Plus they don't have to use the official developer machine for their local repos.  Most developers also run local repos on their own boxes and will push/pull with their public repo on their developer account, or github, or other places.<br></div><div><br></div>-Matt<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 12:25 PM, Matthew Dillon <span dir="ltr"><<a href="mailto:dillon@backplane.com" target="_blank">dillon@backplane.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>