Sure, since ‘s’ isn’t a hex character. *grin*

One’s view of the relationship of Git to code review probably depends on exactly how you use Git. And there are as many ways to use Git as there are people using Git. I’m personally very much in the camp of “clean history”. I want my history to have logically separated commits with nice commit messages that look like they were written perfectly at the first go. Even when they weren’t. I don’t want a lot of “fix typo in a3f5sd” type commits. So, if I’m doing the work with ‘git commit –amend’ ‘git rebase -i’ and so forth to produce nice history, I might as well do that work up front *before* I ask someone to review my work. The commit messages and the logical separation will be a great help in reviewing the changes. Squashing everything on the feature branch together and presenting that for review is not as good.

If, as the result of review, I need to change one of the patches that is not at the top of the “stack” of commits, that can, of course, be a little challenging. My general approach would be to write an add-on patch and commit it at top, then use ‘git rebase -i’ to move it down the stack and squash it with the original commit. This usually works great, and any conflicts are easy to resolve during the rebase process. If one of the older patches has to be substantially rewritten, then other techniques like creating new a new branch and cherry-picking onto it may be more useful.

Once I have the new revisions of my patches I can attach them individually or en masse to the bug with git-bz and obsolete the old revisions. The default idea of patch identity with git-bz is simple – if two patches have the same Subject, they are probably revisions of the same commit rather than independent commit, but you can easily override that and mark other patches as obsolete instead.

What isn’t always so easy to deal with here is viewing the incremental changes – if someone submits A->B->C then obsoletes those three patches with four patches A’->B’->d->C’ – the squashed approach is certainly conceptually simpler. But that doesn’t that mean that the chunking isn’t still useful; I want to be able to look at B’ with the parts that changed highlighted and say “OK, that’s good now” and mark that patch as ready to commit, even if A is still under discussion. I haven’t started on interdiff support at all in Splinter and I’m not sure how well I’ll be able to do. As well as being defined as simple and llghtweight, it’s all written in Javascript on the client side, and while Javascript implementations of sha1, diff, etc, do exist, the performance probably won’t be managable if it the algorithms get too complex…

I should emphasize that Splinter isn’t an official GNOME Sysadmin Team project, or even a sysadmin project at all. It’s something I’m hacking on personally because it’s fun and because I needed it. (I’m already using a private instance to do my gnome-shell code reviews.) If I continue liking it, if other people want it, I’ll push for getting it installed onto bugzilla.gnome.org, but it’s not at all exclusive with someone working on a ReviewBoard instance for gnome.org.

It sounds like there is some good development going on in the area of extensibility that should allow for nice Review Board Bugzilla integration. I’d also imagine that some of the areas where ReviewBoard and post-review seem to me like not a perfect fit for Git will be smoothed out as Git is used for Review Board development itself. The attractiveness of ReviewBoard over time should only increase.

Single-sign-on: yes, both Review Board and Bugzilla support LDAP and the GNOME accounts database (what Mango frontends) is in LDAP. But a) it’s not self-service b) it’s not open for sign-up without applying for some sort of GNOME account. So there’s significant infrastructure development work there.

Multiple IDs: My concern really wasn’t that we’d always have two identifiers for the *same* thing, but that we’d have multiple types of identifiers that would sometimes overlap and sometimes not and it would be unclear what to use where.

Please don’t take the obscure conversations away. While they may be a bit intimidating they also hold a weird attractive power. They need to be Googleable.

Trawling Bugzilla logs is one of my main places to pick up those gold nuggest that are not documented elsewhere. Speaking for myself at least

We have integrated Git support directly into Rietveld and our tool git-cl (http://neugierig.org/software/git/?r=git-cl) does feature many of the pieces you seek (such as patching changes in off the review site, and including review URLs in commit messages).

In general, I think convincing people to use systems they didn’t build themselves is hard; WebKit, an important upstream project of ours has their own suite of tools for meshing bugzilla and git (including a send-to-bugzilla tools as well as tools to go to the otherway, automating patches) and, despite our attempts to bridge the gap, have been building their own bugzilla-integrated system for code reviews.

I don’t know if I can apply a value judgement to all this in the presence of Review Board beyond “it’s sure a bummer so much work is being done over and over again”. In some situations, having a variety of tools in a space leads to healthy competition and crosspolination; in others, the sort of disconnected island feeling I get whenever I look at launchpad.

I’ve thought a lot about git and code review over the years and I’ve written up some thoughts on why I think patch series are the wrong unit of a review here: http://neugierig.org/software/git/?url=git-cl/tree/README.codereview . I’d love to hear your thoughts on it.

http://reviews.mono-a11y.org

However, git-bz is also a great tool and I use it all the time for my GNOME work.

Ideally, I would have the best of both worlds. Fortunately, Review Board has recently moved itself from SVN to git, and the developers have stated a strong interest in improving the git workflow. So I think it’s not overly optimistic to think that with so many people eager to move in the same general direction, we can end up with something that gives most people what they want.

A git-pr that somehow merged the UI of git-bz with the features of post-review would be quite sweet!