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

41–50 of 168 posts

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#41

Post by jasonlotito »

ozim wrote: post #9

What I miss in article is for how long they are on it. Is author after peak of inflated expectations? I have used Gerrit in my previous team and it did not worked so well. Hanging vetos on -2 are not that nice when you have to push feature forward, like instead of blocking it someone else could just fix it, by the time you talked person who put -2 to change it to -1. But maybe with more mature team it would not be a…

We've been using Gerrit since 2011, and it's worked really well this entire time. It does require communication if you have different features in different patches, but frankly, it's light years ahead of anything GitHub still has to offer in terms of pure code reviewing capability.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#42

Post by jasonlotito »

Touche wrote: post #37
therealmarv wrote: post #23

Earlier quoted context omitted.

I'm not a git expert but I've contributed to repos which refused to merge the github pull request to keep their history clean. I mean, seriously?! So I don't know what is better...

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

If you don't understand, then clearly you should investigate why as you cannot form an opinion on something you don't understand.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#43

Post by Touche »

jasonlotito wrote: post #42
Touche wrote: post #37

Earlier quoted context omitted.

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

If you don't understand, then clearly you should investigate why as you cannot form an opinion on something you don't understand.

I have investigated, why are you assuming I have not?

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#44

Post by VLM »

simula67 wrote: post #27

Nothing about what was wrong about gitflow. One small correction I would like to make to gitflow is that the default branch for developers should be 'master'. If you want to deploy another branch, use a 'production' branch. This means people don't have to manually change branches everytime they clone, that type of repetitive work should be outsourced to a computer ( your deployment scripts ). If you have full access…

Jenkins should always pass master. develop is for things that need to be done but necessarily mean Jenkins is at least temporarily very unlikely to succeed and thats "OK" or even "normal".

Or another way to put it is develop doesn't even have to compile. I mean, it would be nice if it does, but its OK if it doesn't.

master might not do what the end users think its supposed to do, but at least it compiles.

Or another way to put it is develop is for big revolutions and master is for small evolutions.

git flow releases are supposed to actually do what the end users think its supposed to do. Or it actually does what they've been told to expect.

It provides a natural flow of code, from a feature doesn't work but its worth a share, to it compiles but doesn't implement business required feature #1243 or feature #531, to we think it correctly meets the business needs at least as of one definition of need at one point. Or another way to put it is a separation of development process of develop to master from the business requirements of master to a release branch.

I suppose everyone uses it a little differently.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#45

Post by jeremiep »

chadnickbok wrote: post #2

The process might seem more complex initially but think of it like this: If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing. In addition, the new GitHub code review tools addr…

I had the same impression reading the intro; I was done after reading about Agile and consultants. In every single instance I've seen these two combined, mediocrity followed. Even in the cases where they thought they had agility the results were still terrible and unproductive.

Most of the time its people not understanding the tech they're trying to use and instead of spending the time to learn it they look for something they already know how to use or they'll pay someone to do the thinking for them which usually overlooks most of the company's context. I know I'm grossly generalizing but that's the trend I've seen so far.

They'll bash on Git for not being enough like SVN, bash on GitHub/GitLab for not having the same workflow of the previous tool. But will happily pay $200 an hour for someone to tell them what to use/do even if they end up making terrible decisions.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#46

Post by masklinn »

Touche wrote: post #37
therealmarv wrote: post #23

Earlier quoted context omitted.

I'm not a git expert but I've contributed to repos which refused to merge the github pull request to keep their history clean. I mean, seriously?! So I don't know what is better...

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 feature thrice after requirements changed? Probably not. Does it need to be enshrined in the project's commit history? Absolutely not.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#47

Post by zo1 »

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…

Would you care to elaborate what you find wrong/bad about "parallel histories"? I'm curious.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#48

Post by joncrocks »

sickbeard wrote: post #6
chadnickbok wrote: post #2

The process might seem more complex initially but think of it like this: If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing. In addition, the new GitHub code review tools addr…

I've used gerrit and it's much better than github/bitbucket. My knock on gerrit is it requires one "very good" git person to be on the team however it makes it very easy to support a larger team and do cleaner code reviews.

https://xkcd.com/1597/

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#50

Post by ssmoot »

chadnickbok wrote: post #2

The process might seem more complex initially but think of it like this: If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing. In addition, the new GitHub code review tools addr…

Github isn't exactly a utopia of UX.

Yesterday I was looking for a way to refresh an old fork with upstream. I'm pretty sure there was a button for this at one point. I looked. Couldn't find it. So instead I had to:

  $ cd ~/src
  $ mkdir github
  $ cd github
  $ git clone myfork
  $ cd myfork
  $ git remote add up upstream
  $ git pull up master
  $ git push origin master
Or something like that. I think I got lost somewhere along the way trying to checkout the upstream branch (is it "up/master" or "up master"? It depends) but it took 5-ish minutes.

Github may be pretty-ish, but I tend to avoid them these days. They're expensive, and they remove useful features. Fool me once, shame on you, fool me twice can't get fooled again.

Post reply on HN