Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Abandoning Gitflow and GitHub in favour of Gerrit

beepsend.com

Post reply on HN
Print view View original

121–130 of 168 posts

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#121

Post by lukeasrodgers »

eridius wrote: post #89
piotrkaminski wrote: post #85

Earlier quoted context omitted.

You might want to check out https://reviewable.io . It has most (if not all) of the goodness of Gerrit, but is trivial to set up (SaaS) and integrates smoothly with GitHub. Every PR becomes a review and gets automatically updated whenever you push to the branch. Disclosure: I'm the founder.

Wow, the described feature set sounds pretty good. I'll definitely look into this. However, I will say the demo is a bit odd. It's pretty much impossible to look at the code diff because there are comments everywhere . And the code diff appears to default to not actually showing a diff (the left and right diff bounds are both set to the latest version), which is especially confusing when it shows side-by-side since i…

Our team started using reviewable.io a few weeks ago, and I quite like it so far. It solves the "squash/rebase->force-push->lose history" problem with Github PR review.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#122

Post by Karunamon »

masklinn wrote: post #46
Touche wrote: post #37

Earlier quoted context omitted.

I've never understood why people think omitting a historical event keeps their "history clean".

Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches". This is combined with most of the "historical record" really being worthless garbage: does it matter that you had to implement 12 fixups at various points and rewrite the whole…

does it matter that you had to implement 12 fixups at various points

If you want to come back later during a git bisect and find out exactly when that bug that just took down your production application was introduced, then yes, absolutely. I'd rather look through 12 small commits than one monster one for that use case.

Look at it this way - a bisect cuts the search space in half with each progression, so you can double the number of commits being searched with the relatively minor cost of adding one more call to bisect when bughunting.

If you're tagging your milestones appropriately and otherwise practicing good repo hygiene, having n number of extra commits for any value of n is a feature, not a bug.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#123

Post by desireco42 »

xori wrote: post #81
desireco42 wrote: post #52

What I got from this article is idea to squash every pull req into a single commit. I think this is valuable idea.

I agree, which github now does for you https://github.com/blog/2141-squash-your-commits

thank you for pointing this out for me

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#124

Post by brown9-2 »

balls187 wrote: post #112
daigoba66 wrote: post #91

Earlier quoted context omitted.

Team members can also work in their own private branches that are pushed to a single repository - that's usually sufficient as a "backup".

That requires push-access. Not all team members have push access to all our source repositories.

Allowing someone to push branches to the "central" repository versus requiring them to have forks of it is functionally the same thing, assuming you set up branch protection for master.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#125

Post by brown9-2 »

Gerrit is being used by many large open source projects,

It should be worth noting that those large open source projects have very, very different needs than a small development team working on a product together. The open source project likely isn't doing weekly releases (which require some sort of manual QA process, in the source article). A large open source project has hundreds of contributors, where reviewer time is scarcer than contributor time (and the pool of people to approve and commit a change is much smaller than the contributor pool).

I think the OP's real problems are that:

- an increased release frequency requires them to do more QA

- their time spent in code review seems to be a function of how often they are "releasing", not how often people are making changes

If the difficulty of making a release increases as you increase your release rate, you might be doing "agile" in a poor way.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#126

Post by superuser2 »

eridius wrote: post #82

I really want something that provides better code review than GitHub. The described code review features of Gerrit sound promising. But the article says you can't submit a series of commits for review as a unit, you only submit a single commit. Is that really true? That seems like a rather awful limitation of the system. Sometimes my changes work well as a single commit, but often, especially when doing more complica…

Phabricator[0] is awesome. Diffs (like PRs) contain several commits, but are reviewed, discussed, and "landed" as a unit with an auto-generated commit message referring to the Diff description and a link to read its history, but "master" is a linear sequence of Diffs being landed. You can also configure all kinds of rules like "X person must sign off on any changes to this file" or "do not merge code to master unless it is approved by N people other than the author." The UI is a bit clunky but I love it, and it's open source and very flexible.

[0] http://phabricator.org/

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#128

Post by finnh »

superuser2 wrote: post #126
eridius wrote: post #82

I really want something that provides better code review than GitHub. The described code review features of Gerrit sound promising. But the article says you can't submit a series of commits for review as a unit, you only submit a single commit. Is that really true? That seems like a rather awful limitation of the system. Sometimes my changes work well as a single commit, but often, especially when doing more complica…

Phabricator[0] is awesome. Diffs (like PRs) contain several commits, but are reviewed, discussed, and "landed" as a unit with an auto-generated commit message referring to the Diff description and a link to read its history, but "master" is a linear sequence of Diffs being landed. You can also configure all kinds of rules like "X person must sign off on any changes to this file" or "do not merge code to master unless…

I used phabricator at my last job and was really impressed. Now I'm using Gerrit and I'm less impressed (but still getting used to it).

You say clunky, but Phabricator's UI makes Gerrit look like a WAP app.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#129

Post by aeorgnoieang »

edgan wrote: post #93
aeorgnoieang wrote: post #12

There's a Gerrit service that integrates with GitHub: - [Gerrit Code Review for GitHub]( http://gerrithub.io/ )

If only it was only code review. This is basically another GitHub git hosting service using gerrit, and it syncs to github for open source projects. I don't want a new hosting service, I just want a code review process on top of GitHub.

I'm confused. It syncs (some of) your repos and any PRs in them, so what else do you need to do with it besides code review instead of with GitHub?

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#130

Post by balls187 »

brown9-2 wrote: post #124
balls187 wrote: post #112

Earlier quoted context omitted.

That requires push-access. Not all team members have push access to all our source repositories.

Allowing someone to push branches to the "central" repository versus requiring them to have forks of it is functionally the same thing, assuming you set up branch protection for master.

> assuming you set up branch protection for master.

Bad assumption. However, branch protection sounds cool. Will investigate it.

Post reply on HN