how dragonfly uses git

[Thomas Klausner <tk%giga.or.at@localhost>]

Matthew Dillon wrote up how DragonFly uses git. Quoted inline since
it's not so long.

http://lists.dragonflybsd.org/pipermail/users/2015-January/207421.html

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

http://lists.dragonflybsd.org/pipermail/users/2015-January/207422.html


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


http://lists.dragonflybsd.org/pipermail/users/2015-January/207424.html

[answering a question by mspo]
: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?

    Shared group works well.  Here's what the config file looks like in
    the master repo:

    We do use git-shell but I wrote a little wrapper for it called
    git-ssh-command that execs it with 'cmd' as a single argument to -c
    (taken from the SSH_ORIGINAL_COMMAND env variable).  I don't remember
    why I did that, it was a very long time ago.

    	      	       -Matt

[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
        sharedRepository = group
        packedGitWindowSize = 64m
        packedGitLimit = 256m
[pack]
        packSizeLimit = 64m
[hooks]
        mailinglist = commits at dragonflybsd.org
        emailprefix = "git: "
        gitweburl = http://gitweb.dragonflybsd.org
[gc]
        aggressiveWindow = 100
        auto = 0
[gitweb]
        #owner = The DragonFly Project
        owner = Fred

				-Matt
 				Matthew Dillon 
 				<dillon at backplane.com>