dfbsd git setup

[Matthew Dillon]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20150129/c6177a5c/attachment-0003.htm>