dfbsd git setup

[matthew sporleder]

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.
>
> -Matt
>
> On Thu, Jan 29, 2015 at 12:25 PM, Matthew Dillon <dillon at backplane.com>
> 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 <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
>>
>>
>