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

111–120 of 168 posts

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#111

Post by balls187 »

goldbrick wrote: post #92
balls187 wrote: post #80

Earlier quoted context omitted.

> You don't have to do this with Github. Just clone directly to your local machine. If you use this model, your local clone isn't "backedup" by github until the pullrequest is merged, correct? One reason I like my teammembers to have their own local fork, is so they can have github exist as a backup.

Why would you not be able to use Github as a backup? Github keeps all the branches that are pushed to it, as any git repo.

If you have push access to the repository sure.

What if you don't have push access?

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#112

Post by balls187 »

daigoba66 wrote: post #91
balls187 wrote: post #80

Earlier quoted context omitted.

> You don't have to do this with Github. Just clone directly to your local machine. If you use this model, your local clone isn't "backedup" by github until the pullrequest is merged, correct? One reason I like my teammembers to have their own local fork, is so they can have github exist as a backup.

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.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#113

Post by djsumdog »

1_800_UNICORN wrote: post #104

Gerrit is the wrong solution for truly agile software development. I had a client ask my team to use it, and it was a real PITA. The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. It's unrealistic to ask someone to code review multiple commits per feature, and if you tie in your CI it doesn't make any sense to run your build over and…

I used Gerrit for over a year at one company and I have to agree. Every minor change required amending a commit and another review. It really breaks a lot of the git process.

I also had to admin a Gerrit server once and the documentation (at the time at least) for setting up and running a Gerrit server was total shit. It was a painful process to say the least.

Another project, which took many of my old team members, started using Gitlab instead and they loved it. The merge requests made a lot more sense. I'm currently at a new company that uses Gitlab and I have to agree.

Both systems are pretty much suggestive. We could always +1 a code review ourselves if it had to get out that day, but it's best someone else did it and there was a record. Gitlab is a lot more lose. There's no official field for an approval, but you can put in a nice little thumbs up emoji in your comment, and you have the same audit trail.

TL;DR +1 Gitlab (et al.) over Gerrit for sure

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#114

Post by daigoba66 »

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.

honest question: why don't they have push access?

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#115

Post by xyzzy_plugh »

1_800_UNICORN wrote: post #104

Gerrit is the wrong solution for truly agile software development. I had a client ask my team to use it, and it was a real PITA. The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. It's unrealistic to ask someone to code review multiple commits per feature, and if you tie in your CI it doesn't make any sense to run your build over and…

> if you push multiple dependent commits to Gerrit, and one of the early ones gets merged, all of the later ones now have to be rebased because Gerrit created a merge commit in the middle.

Someone didn't spend time configuring gerrit or configured it wrong for your use cases. You can solve this in one of two ways: you either fast-forward when possible (gerrit can attempt a trivial rebase) or you commit a change set, create your own merge commit, and then your early ones won't get merged until your last commit. Gerrit will wait to merge the early commits (and vice versa if dependant commits are ready) until everything is good, then merge them all in one shot.

I used gerrit heavily for a few years (and still do, passively, with golang and other public google projects) and I miss it dearly. Sure it's not perfect, but I'd take it over the github fork/make pull requests model any day of the week.

It does not encourage monolithic commits. You need developers to understand what they are doing, care about commit history and be disciplined during development. In my experience, developers who just want to hack shit together, cut corners and love squashing commits or throwing away history hate gerrit. Developers who care love it. It's definitely possible and easy to produce Agile software.

Like anything else, you should use the right tool for the right job. If you're not willing to suck it up and learn something new, then it's not going to have a chance to be the right tool.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#117

Post by caoilte »

u801e wrote: post #88
marssaxman wrote: post #67

Earlier quoted context omitted.

I've yet to find a situation in which I cared even a little bit about the prettiness of a git history. I am having trouble thinking of more than a couple situations, ever, where I cared about the contents of a git history, at all! I imagine that people must be doing something involving git history which I simply don't have reason to do, or this "make your history pretty by rebasing" meme wouldn't keep floating around…

> I've yet to find a situation in which I cared even a little bit about the prettiness of a git history. I am having trouble thinking of more than a couple situations, ever, where I cared about the contents of a git history, at all! For me, it's the ability to use git blame and determine which commit was responsible for a line of code and read the commit message about why it was added. If you don't keep a clean commi…

Blame is occasionally useful, but for me more than half the time the file gets moved somewhere else or the indentation changes as part of some other change so you lose all context about the original commit.

The code is the thing for me. And the less of it, the better.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#118

Post by ionforce »

hinkley wrote: post #26
oluwie wrote: post #8

Earlier quoted context omitted.

Gerrit does favor rebasing over merging but that's hardly a reason to run away from it

Rebasing is great for version history but is hell for collaborating on a feature. If anything is the Achilles' heel of Git (aside from the groundbreaking levels of inconsistency in the CLI) it's this. the moment someone creates a new version control system that has most of what Git does but fixes parallel histories, I'll switch. And I don't mean that the way people say "if Bush wins again I'm moving to Canada." I say…

What do you mean by "fixes parallel histories"? What is a parallel history and how do you fix it?

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#119

Post by eridius »

timr wrote: post #103
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…

I've been working on a code-review tool that does exactly what you want: https://www.omniref.com/code_review It works seamlessly with GitHub, and provides code reviews that end up "sticking" to your code, and documenting its development. Every pull request you create can become a review automatically, or you can pick-and-choose which pull requests to review. And you don't lose reviews or comments when you push to a b…

Looks promising. Does it handle force-pushes to PRs? It says it doesn't lose comments when pushing new commits, but it doesn't mention how it handles history rewriting.
Post reply on HN