seems like git isn't designed to handle long-running branches, or branches with more than one committer. i'm still pretty novice at git, and was hoping this article could clear that up, but mailing patches around seems .. inefficient.
anyone want to correct me? i like git in most respects, and am now using it on a few projects.
Did you realize that your master/ branch is just one such long-running branch, and one that's not special in any way other than being the default for some commands...
As far as multiple committers on one branch -- well, you can do it, but with 'git rebase' and friends, it's just easier to do your own work on a short lived branch off your primary branch, and just merge in stuff as you get it done.
It's not that git makes it difficult to do it compared to other version control systems; it's just that it's a nicer workflow if you use short-lived topic branches to do development because you don't to worry about what other people are doing until you decide you want to take a look at it and merge it in. The short-lived private branch + lots of merges workflow is just easier because it prevents interruptions in your workflow.
As far as emailing patches, it's a matter of taste. It's certainly easier to make sure all changes get reviewed if patches are mailed around, because people tend to read their mails. Personally, I just use a post-update hook to mail out a list of changes for each commit, and review them later, since it's always relatively easy to back out or fix a patch -- after all, it is a version control system.
with git you don't checkout, you clone. then you branch that clone locally. if you want other people to work on that branch, you can git push that branch to the origin server repository, and other people can then git pull it, and of course any member can then simply git push it whenever they commit and it will be widely available.
anyone want to correct me? i like git in most respects, and am now using it on a few projects.