Thanks for the great writeup! Why not use git-shell instead of command= stuff?
Also do you happen to do anything special with permissions on the git repo or is shared=group + setgid stuff enough to keep everything sane? On Thu, Jan 29, 2015 at 3:38 PM, Matthew Dillon <[email protected]> wrote: > 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. > > Right now, for example, I have a 'wlan' branch in my local repo at > git://leaf.dragonflybsd.org/~dillon/dragonfly.git 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. > > 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. > > 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. > > -Matt > > On Thu, Jan 29, 2015 at 12:25 PM, Matthew Dillon <[email protected]> > wrote: >> >> 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 <[email protected]> >> 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 >> >> >
