Andrei,
Thank you for your reply -- it is very informative! A few follow-up questions below:
On 09/30/2010 07:06 AM, Andrei Pelinescu-Onciul wrote:
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).
Do you know if this restriction mechanism also part of a standard suite of scripts that are associated with git in one way or another, or something completely custom that was written specifically to manage permissions centrally on your side?
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 Janakjan@iptel.org # Updated by Andrei Pelinescu-Onciulandrei@iptel.org
Oh, okay. Yeah, I am familiar with this script. I was just wondering which one you were using, even if you have hacked it.
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.
So, all contributions to the central repository are ultimately done by pushing, never pulling?
Do all validated developers have write access to the master branches? Or do 'core', everyday developers like you have write on the master branch, while more distant, occasional contributors only have write to branches named after themselves, and core developers review/merge their changes?
Do you do any "cherry-picking" from time to time from smaller or less consistent contributors? If so, how do you do it? The only process with which I am familiar to do this is to 'git fetch' (not pull) someone else's changes, 'git cherry-pick' them out of the list of commits that appear in the range HEAD..FETCH_HEAD (or master..eval_repo if you 'git fetch'ed those changes straight into a new branch called 'eval_repo'), then blow the rest of the FETCH_HEAD/eval_repo differences away (git checkout master; git merge eval_repo -s ours). Do you do something like this?
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.
How do you handle the integration of those branches into master? Do you keep them local only while you are developing, and then, when you are ready to push them into the master on the central repository, do something like:
1. git checkout master 2. git pull [to update the local copy of the master branch from server] 3. git checkout feature_branch 4. git rebase master [solve any conflicts between master and feature_branch here, better to have the conflicts in the branch than in the master] 5. git checkout master 6. git merge feature_branch 7. git push
Or do you keep even your experimental / large feature branches pushed to the central repository commonly so that people can see those changes and look over them and cherry pick things out of them perhaps?
Also, what are your commit policies like? As you know, Git allows much more granular management of commits so that they can be organised to contain hunks that reflect related changes conceptually, rather than just unavoidably being a log of files changed over a certain period of time (like SVN or CVS). Do you insist that developers make very clean commits, stepping through each patch hunk with 'git add -p' and classifying it, or is this a matter of personal custom, habit and taste? Do you go back, as a maintainer, and compact a lot of small commits into big ones by rebasing them often?
In general, it sounds to me like you are mainly using Git in rather centralised, SVN/CVS-like ways, but in ways that take advantage of Git's cheap branching more effectively. Other than being able to branch easily -- which you don't really even do a lot of -- what do you perceive to be the main advantage of using Git?
Thank you for your insights!
-- Alex