Below are a set of comments and process descriptions adopted by Deltacloud in relation to Git.
This comes from a private discussion and I only have permission to repeat the words of David Luttekort (other posters did not withhold permission, but they've not granted it explicitly, so I'm being cautious, as a result I've edited Davids words occasionally so they make sense where I've cut a previous comment). I wonder if this content would be useful for the wiki or for driving discussion about whether these are optimal approaches. I'm not a git user (at least not in a project with more than two committers) so I don't feel qualified to comment directly. David says (I've injected a few comments/questions in [square brackets]): I'll share some of the experiences that Deltacloud had; since the project started on git, and switched to svn only because of entering the ASF incubator, the project's workflows and conventions are about as close as you can get to a git-only project while using git-svn. [Push rates vary.] The workflow that Deltacloud (and a lot of git-centric projects) use is review-before-commit, i.e. you post your proposed patches on the mailing list, and should only commit them to the central repo (now done via 'git svn dcommit') once at least one other person has reviewed and ACK'd them. [Most ASF projects operate on RTC for non-committers and CTR for committers - is this likely to change with Git? Should it change? If it need not change how do we ensure frequent pushed from committers?] Patches from non-committers are committed by a committer on the non-committer's behalf. Unfortunately, svn does not preserve the separate Author and Committer roles that git does; we've therefore switched to using 'Signed-off-by' to make sure we record the original author of a patch. Of course, committers are responsible for checking that patches they commit for others are backed by a CLA etc. [The issue of SVN losing Author and Committer roles will disappear with a Git central repo. What is the optimal process for handling non-committer patches then?] [People mostly share changes] on the mailing list, sending patches around (for those who haven't used git a lot: git makes it very easy to work with patch series from others, in parallel to your own ongoing work) I personally find github's model of sending merge requests and merging in other repos less productive, in particular since I am very strict about maintaining a linear master branch (git-svn forces that, but even for my non-ASF projects do I insist on that, since it makes things like bisecting a ton easier) [Do you agree with these observations about GitHub merge requests? Are we likely to find this model the norm. for people using GitHub? Do other Git hosting environments encourage this workflow? What is the optimal process for an ASF project?] On occasion, I've uploaded a patch series to my people.apache.org page, usually when the patches are huge and there is danger that they get mangled in email. [Does the ASF need some facility for this?] In other projects, I've merged patches directly from other people's repos, but as I said, I find that more annoying than applying a series of patches directly. > Branches in the ASF repository, or are people hosting them elsewhere? For Deltacloud, we do not have any public branches. I think there were one or two occasions in the pre-incubator days where we had a public branch because we did a fundamental overhaul of the codebase and didn't want to disturb the ongoing work on the master branch. Whether you see a lot of public branches in a git project depends a lot on how the project takes in contributions: via merge from other git repos, or through patches posted to a mailing list. But even when contributions come through merging of other git repos, you rarely see branches in the canonical git repo. There, you'd expect to see branches for exactly the same reasons you'd see them in svn: to support longer-lived work that deviates from master. [There's that same alternative process again? Any more comments in this context? Should ASF projects be encouraged to follow one process and not the other? Should it be left to individual projects?] [How git affects the community] highly depends who the community members are: if they have a strong git background, they'll be unhappy with svn; if they have a strong svn background, they'll be unhappy with git. And not just the tools, but also the differing workflows these tools accomodate. [If a project moves to Git how to we minimise the pain for SVN users? If a project stays with SVN are the Git mirrors we currently have the best we can do for Git users? Can projects that stay on SVN benefit from lessons learned in the GIt projects?] [GitHib is not necessary to get the most from Git] IMHO, a gitweb instance would be good enough for Deltacloud; a gitorious instance of course much shinier. Whatever infra feels is the best tool from their side would be fine by me. [Is a plain vanilla Git repo enough? What do we *need*? What would add additional value?] On the subject of tagging releases; I've only been doing this on my private git repo, but think it would be a sensible recommendation for public repos: I generally tag releases and release candidates using 'git tag -s release-1.2.3-rc7' at the same time I run 'git svn tag'. The important thing is to pass '-s' to create a GPG signed tag so that it is later reproducible without any doubt from what state of the source repo the release artifacts were generated. [In SVN tagging of releases is a critical part of our release management processes. What are the equivalents in Git?] Thanks to David for taking the time to share his experiences and giving me permission to post them to a public list. Thanks in advance to the git experts here for using this in whatever way is most appropriate to move us forwards. Ross
