Some general comments about git repository and commit policy

[Daniel J S. <dan...@ie...>]

Ethan mentioned offline old CVS branches, that brings to mind something 
about git worth mentioning for those maintainers not familiar with git. 
git uses terminology "branch" quite often, but after working with git 
for a while one will realize the "branch" analogy fails a bit after 
merges are done.  More accurately, git pushes the heads along.  It's 
important noting this because once two branch heads are merged, the 
names once associated with those branches are lost and one doesn't know 
what branch was what at the time they were under development.

For example, say I create a branch from "master" called "sebald001" with

git checkout -b sebald001

I then make some commits on "sebald001", while on "master" some other 
commits are made by others.  If the two are merged, it's not obvious 
what changes were done at the time on "sebald001" versus those that were 
done at the time on "master".

The reason this is important is because often git projects have a rule 
of no modifications on the "master" branch, only merges.  So, even the 
smallest of mods are done as a branch and then merged.  Whether you want 
to do that here, where there are a lot of people submitting changesets 
and patch sets is worth discussion.  I believe that any submitted 
changesets can be rebased locally by the maintainers to fit any model 
you decide upon and then pushed to the main repository.

In any case, there are some logistical and procedural things the 
maintainers will have to decide on.  I just want to point out that 
although git gives a ton of flexibility in terms of merging branches it 
can be real confusing after the fact to know exactly how things 
progressed when there are intertwined multiple merged branches.

Dan