[sr-dev] OT: How do you use Git?

[Andrei Pelinescu-Onciul]

On Sep 29, 2010 at 19:58, Alex Balashov <abalashov at evaristesys.com> wrote:
> Hi Daniel, Andrei, Jan, etc.
> 
> I have been trying to learn Git so that I can maybe help with the
> documentation on the project like I said once I would.  Along the
> way, I have become curious how the project is managed as it relates
> to Git.
> 
> I have read over Jan's impromptu Git tutorial that he posted on the
> Kamailio-devel list some time ago to try to help out people
> switching from SVN, but still have some questions.
> 
> I am curious, what methodologies and tools do you use for hosting the
> central Git repository for sip-router?  For instance, what scripts
> and tools are used to generate e-mails about submitted patches to
> the
> sr-dev list -- are they standard ones that come with Git, or
> something handcrafted or third-party?  Also, how do you handle
> automated pushing and pulling of various developers' branches?  Does
> the system only pull your personal branch, so that any topic
> branches you make are purely your own and when you want them put
> into the mainline code, you merge them into your main branch so they
> get pulled upstream?  What does the workflow/process like?


Repository:

Each developer has an account on the git machine (with a restricted
git-shell).
We have a modified update hook that takes care of permissions and calls
the mail script.
The update script is a modified version (I don't remember how "heavy")
of
http://www.kernel.org/pub/software/scm/git/docs/howto/update-hook-example.txt
(or at least of the version that was there 2 years ago).

For the commit permission the update hook looks into another file, in
which we have a list of:

branch_pattern user_pattern_list

(both of them are regular expressions)

If the branch_pattern and user_pattern match for a specific commit, the
commit is allowed.
Besides that any commit on a "username" branch (of the form $user/.*)
is allowed as long as the username of the commiter is the same as $user
(this can be turned off using a config option).

The relevant parts of the branch permission file for sip_router are:

# everybody can do any change in tmp/* branches
+refs/heads/tmp/.*      .*

# everybody can do any change in kamailio/* branches
# - used to release kamailio stable versions
# - naming pattern: kamailio/major-version: kamailio/3.0
refs/heads/kamailio/.*  .*

# everybody can commit on the master branch
refs/heads/master$      .*
refs/heads/sr_3.0$      .*
refs/heads/kamailio_3.0$        .*

# everybody can make any tag
refs/tags/.*            .*


[besides that there are some restriction for old branches inherited
from ser and for the ser sync branches, which are not used anymore]


The mail script is again a modified version of some perl script. I do
not remember were we took it from. Here is its header:

# V0.4 (mails for never seen before commits)
#
# Tool to send git commit notifications 
#
# Copyright 2005 Alexandre Julliard
# 
# Updated by Jan Janak <jan at iptel.org> 
# Updated by Andrei Pelinescu-Onciul <andrei at iptel.org>

We also have an email_map file, mapping local usernames on the machine
hosting the repo to the email addresses that you will see in the From:
line of the commit mail. If no match is found (somebody forgot to update
email_map), the from line will use admin at ...).


Workflow:

There is no automatic pulling or pushing.
The developer chooses the branch on which he wants to push his changes.
As long as he has write permissions on that branch it will work.
While a more restricted workflow would be theoretically better (e.g. each
developer can push only on his branches or some tmp/ branches and
then send pull/merge requests to some maintainer which would merge the
developer branch into master or stable), most people are used with the
CVS/SVN one branch-for-all model.

In general I try to use separate branches for bigger features (requiring
several commits). It's easier for me (because I don't have to update the
code everyday, I can work on the old version and merge it when ready and
in the meantime I can switch between several branches with
work-in-progress), it's easier to completely revert if needed and the
history looks nicer.
If I have only small fixes or small features I commit directly to the
master branch.
I also have several local branches for testing various smaller features,
that I constantly rebase and push to the public repository only when
ready.



Andrei
P.S.: if you want to see the scripts I can send them to you