News for hackers. Stuff that matters.

A comment on Git and github are not change management tools (rewriting history in git). Parent comment

Re:Git and github are not change management tools (rewritin... by tytso on Wednesday August 10, 2011 @11:34AM (#2868692)
I've been regularly sending patch series to Gerrit, and it works fine. If you're not seeing the previous review comments that's because either (a) you're not adding the Change-ID: lines, or (b) you haven't tried diff'ing against the previous version of the patch (in which case the review comments will be clearly visible). Also, the review comments show up in e-mail, of course.

It's true that Android uses a lot of cherry-picking and rebasing, but that's because they have to support a large number of releases. That's a development process choice that the Android folks have made --- but it's not fundamental to Gerrit.

At least the modern versions of Gerrit have a lot of configuration options, some of which can be set on a per-user basis (via ACL settings). It's certainly not perfect, but it is actively being developed, and it is getting better...

[ Parent | on HN ]
Re:Git and github are not change management tools (rewritin... by exDM69 on Thursday August 11, 2011 @05:57AM (#2872155)
The problem is that when I upload a new patch set for a change that already exists, all the review comments I had on the previous patch set are "lost". Also finding the differences between two patches in a change is difficult.

What I'd really want to do in this situation is to have a feature branch where I push another commit for review. The difference is clearly visible and I can get new review comments without losing the old ones. This works very well with Git and GitHub.

[ Parent | on HN ]
Re:Git and github are not change management tools (rewritin... by dlsspy on Friday August 12, 2011 @10:13PM (#2880018)
That's exactly how we use gerrit. The most recent change in our gerrit install is on its sixth revision:

   http://review.couchbase.org/8560
I pulled this one arbitrarily, it just happened to be the top. It's got a dependency and they change together. It works flawlessly and almost entirely transparently as long as you have a Change-Id (for which there's a simple hook to generate).
[ Parent | on HN ]