HiSo with those thoughts in mind I want to ask two basic questions: Simply that a well maintained Git repo is available and clearly documented that there is a commitment to remain up to date (eg it's implemented in an automatic fashion) For mild preference I would like the git repo hosted somewhere that encourages forks to remain visible, eg Github. However, there is a whole new can of worms by suggesting that, so I will leave that as a separate suggestion. 2) For those who currently use git what sorts of processes can we have today, without moving currently, that will help you get more out of using git with ledgersmb? This is an important one because even if we move in the future, it isn't clear we'd entertain direct pull requests. We might use git just to make it easier for people to maintain mini-forks and share features between such. (My understanding is this is largely how PostgreSQL uses it for main development, and my guess is that virtually all patches still come in via email.) Opinion is divided on whether pull requests are that useful. Linux kernel takes external contributions via email and that is what the "git am" command is for. Possibly this is something you currently feel requires a script for svn users to implement correctly, but under git there should be no need, eg you might develop like this: // Make feature branch git checkout master -b my_fork // do some work... // ... git commit // do some work... // ... git commit // rinse, repeat, etc // Now, assuming master has moved on, ensure that our patches apply perfectly to HEAD git fetch git rebase master // Submit patches // Generate complete email: git format-patch -1 -s // or send the emails as well: git send-email You the developers can apply patches using either git-am or git-apply (am reads the patches right out of a mail file, apply assumes you saved them to disk first). So, yes, email is probably the simplest way to accept new patches with git, however, one of the nice things about public git hosting (especially github/gitorious) is that you have the option to "poke around" and do a git-pull or git-cherry-pick if appropriate. I personally rarely git-pull stuff though unless I very much trust the upstream - mostly I work with patches Oh, final useful thing is maintaining git-branches and git-tags that correspond with the actual releases. This should come across automatically from SVN, but just highlighting it's a nice to have Cheers Ed W |