First, my response to Doug's original email: > I need to figure out how Git fits into the Apache development style. > Git has not been used much at Apache, certainly not in any project that > I've been involved in. I also have never used Git and speak largely > from ignorance. Here's one success story. http://www.mail-archive.com/[EMAIL PROTECTED]/msg70294.html
> It should be noted that there have been flamewars within Apache about > the use of Git, and many feel that it doesn't belong here. I don't want > this discussion to degenerate that way, and am trying to address this > with an open mind and hope that others will too. I'm pretty sure I incited the most recent one, but I promise that my style is flame-free. > Apache places building better community over better code as the highest > priority of a project. Healthy communities build better code long-term > (or something like that). One of the hallmarks of Apache communities is > transparency in communications, providing a level playing field for all > members of the community. For example, IRC is acceptable for casual > conversations, but decisions about changes to the project must be made > on project mailing lists, so that everyone, no matter timezone, etc., > can contribute to the discussion equally. It's also important to have a > single venue for discussion, patches, bugs, etc., so that everyone sees > the same information. We are not using Git as a means for communication. So far, we have only used it as a medium for publishing experimental lines of development. All interesting news is broadcast to the mailing list along the lines of "Hey guys, I just did X. You can pick it up on branch Y." I've encouraged all of our developers to push their branches to the thrift-rpc.org repository (formerly known as thrift-git.thruhere.net) even if their "primary" repository is a different one (like on GitHub) so that anyone can go to the branches page and see what is going on. <http://gitweb.thrift-rpc.org/?p=thrift.git;a=heads> > Some projects operate in a review-then-commit (RTC) mode, where, before > a patch may be committed it must be reviewed by another committer. > Other projects operate in commit-then-review (CTR), where committers are > expected to monitor commit messages and can veto changes retroactively. > (Some projects use different modes for trunk than release branches.) > > http://www.apache.org/foundation/glossary.html#CommitThenReview Perhaps we should discuss how we want to do this with Thrift in a separate thread. I've been using RTC for nontrivial stuff, but I also do a lot of small commits without getting an explicit review. > I've mostly worked on RTC projects. In this case, it is important that > each patch is equally visible and easily applicable by every committer. > If some developers are using Git and some are not, how will this work? Here's how I envision it. Say Todd does some work on a Debian package and wants it to go into SVN. He pushes it to a branch on thrift-rpc.org then emails the list. "Hey guys, I just made a Debian package. You can pick it up on the branch 'pri/tlipcon/debian-moved'." Then, everyone goes to the Gitweb front page <http://gitweb.thrift-rpc.org/?p=thrift.git;a=summary> and sees his branch in the "heads" section. (A "head" is what Git calls a branch.) They click on the "newlog" link next to this head. (Newlog is a feature that I added to Gitweb. It is not in the standard distribution, but you can pick it up here if you want it: <http://gitweb.thrift-rpc.org/?p=gitweb.git;a=summary>.) This will show you all of the commits in Todd's debian branch that are not in the SVN trunk. (It is common for Git users to structure their changes as a series of independent commits, rather than a single giant diff.) For each change, you can click "commitdiff" and see the full diff, along with the commit message (which is conspicuously absent from patches posted to JIRA). Maybe we give Todd some feedback. He makes another commit on top of the existing ones and posts it, with the understanding that his intention is to squash it down before committing to SVN. This makes it really easy to see an incremental diff, which is basically impossible with just patches. (It is a little tricky to see the full diff in Gitweb at this point, but I can add a shortcut for this.) Eventually, the branch is approved, Todd squashes all of the "edit" diffs into the proper commits and does a "git svn dcommit" directly to SVN. Actually, Todd is not a committer, so I pull the branch and dcommit it myself. I have found pulling Git branches to be much less error prone than downloading and applying patches. > Will every patch still be posted as a flat file in Jira? Do you see any benefit to posting flat files to JIRA, given the workflow I described? > One possibility might to declare that all members of the Thrift > community will use Git, and that patches will be shared via a shared Git > repository. Another possibility is that, in Jira, instead of attaching > patches as flat files, one might add links to a patch in the Git repo. > However this seems nearly equivalent to using Subversion in CTR mode. I prefer the latter: links to patches in the Git repo. Gitweb makes it *really* easy to download a raw patch or a full tarball of an experimental tree. I think this is really more like RTC mode, since you are reviewing the change in an experimental Git branch before it goes into the SVN repo and dirties up the SVN history. If we were using Git 100% (this is a hypothetical) I would want to use a RTC model for the master branch (trunk), along with a policy that commits could never be removed from master. For our experimental branches, commits can be added, removed, edited, reordered, etc. to build a clean narrative of the development before it goes into the trunk/master. > So, in summary, non-gitters like myself need to understand how we expect > transparent collaboration to function with Git. What is the review > model? I think we should discuss what we want in terms of RTC vs. CTR in a separate thread, but I would prefer RTC for nontrivial changes, with Git used as one possible medium for publishing those changes for review. I'll formalize workflow I described above and put it in the wiki so that someone with zero knowledge of Git can fully review a change using Gitweb with no trouble at all. > It is unacceptable to have subsets of the community sharing > patches that are not yet available to the entire community. Sounds good to me. > When a > patch is first made available for review, it must be made available to > all members of the community. Does this mean we all need to use Git? Absolutely not. All of this information will be available via Gitweb as log views, "commitdiff" (commit message + colorized patch), raw diffs, or tarballs. Also, I'm sure GitHub provides similar interfaces. (GitHub is a commercial Git hosting site that provides free hosting to small projects. The Thrift Git repository is automatically mirrored to GitHub, so all of its fanciness is available on any Thrift patch.) Upayavira made it clear to us that we cannot discriminate against non-Git users, and I have no intention of doing so. --David My response to Carl's email: > Requiring patches to be diffed against Git repos or requiring committers to > use Git could scare potentially helpful people away. The web interfaces for Git (Gitweb and GitHub) provide everything that a contributor will need to review branches pushed to Git. Using Git will absolutely not be a requirement. > Always keeping an established way of submitting work is key. A tremendous > amount of developers are already very familiar with SVN (and it's model). Submitting patches to JIRA will be an accepted method of submitting work forever. But those of us who are comfortable with Git find it far more powerful, and we simply want to take advantage of that power. > But that brings me to another question, in what ways can a Git repo co-exist > with a SVN repo (synchronously) ? I'm not sure what you mean by synchronously. We have no immediate plans to automatically push changes from Git back to SVN. Our Git repo simply tracks the SVN trunk and hosts experimental branches that must be manually committed to SVN. > Also, something is telling me others are > having similar integration problems with Git and SVN. Are there other > projects that are doing or has done the same thing? I'd be interested in answers to this as well. --David
