On Thu, May 27, 2010 at 12:14 AM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
How does that differ from what we do now? Review? I develop in my own branches as is.
Right - so - then do you always ask for a review from someone before merging into trunk? If so, then git is just a much more fluid, reliable and faster tool to do what you are doing now.
True, but what happens when there is no review? I might point out that there are currently tickets with patches for review going back two years and reviewing a patch isn't *that* much harder than visiting github. Using git makes merging changes much easier, but it doesn't solve the review problem.
Well - that's true and not true. The joy of git branches and the ease of merging is that you quickly get into the habit of making feature branches for each piece of work. This makes it extremely easy for someone else to review the changes that you have made. So, it greatly lowers the work needed for someone to review your code, and therefore makes it more likely.
Having said that - it will of course happen that you ask for review and no-one responds. That's not a very big problem, because git merges are so easy that you can - as Anne said earlier - just keep on developing without worrying that your changes will go out of date. But if there's a long wait - or it's urgent - then what I do is just email with 'If I don't hear anything I'll merge these changes in a few days'.
Exactly. I had a private bet with myself that that would be the case. See, it isn't so much different after all. The tools change, but the problems and solutions remain much the same. Given that there are only three people doing reviews, and really only two really looking at the c code, I expect that a lot of stuff will be merged without much in the way of review. Now if git leads to more developers that might change. Here's hoping. Chuck