dfbsd git setup
msporleder at gmail.com
Thu Jan 29 13:18:55 PST 2015
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 <dillon at backplane.com> 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.
> On Thu, Jan 29, 2015 at 12:25 PM, Matthew Dillon <dillon at backplane.com>
>> 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.
>> On Thu, Jan 29, 2015 at 8:35 AM, matthew sporleder <msporleder at gmail.com>
>>> 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?
>>> I appreciate any help,
More information about the Users