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

61–70 of 168 posts

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#61

Post by clay_to_n »

Negative1 wrote: post #56

This is way more complex to me than GitFlow with pull requests. As a matter of fact, if you use something like SourceTree for most of the initial steps it's a few mouse clicks. Also, try Gitlabs for your reviews; it's pretty good! The idea of a more in-depth review is intriguing (we all know this is something that can be improved), but _voting_ on a peer's code just seems like a bad idea. Vote too low, people get ins…

What appeals to me about the voting scale is that it's well-defined: a -2 means "don't merge yet", a 1 means "looks good to me but I'm not sure that it's ready to merge". More of an enum than a voting mechanism.

It sounds like it removes the ambiguity of when you leave a few comments on a PR but aren't explicit about whether you think it should be merged or not.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#62

Post by quicklyfrozen »

ssmoot wrote: post #50
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 t…

You can create a PR from the upstream to your repo, then accept that PR. (I know, that's not immediately intuitive, but at least you can do it without pulling a local copy.)

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#63

Post by fishywang »

codemac wrote: post #58

Anyone know of a good hosted gerrit solution? One of the largest problems I've had getting gerrit adoption on smaller teams is that they can just pop up a private github team easily, whereas finding hosted gerrit solutions that actually make it easy to convert from other source control tooling has been very difficult.

try gerrithub

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#64

Post by xenophonf »

ssmoot wrote: post #50
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 t…

It'd be nice if there were a way to automatically update a fork, including the issue tracker, wiki, releases, etc. The best I've come up with is a set of scripts that iterate over all branches of all forks, running `git checkout $branch; git merge --ff-only upstream/$branch; git push`:

https://gist.github.com/xenophonf/9df09e47a8629bb789ffbb94c7...

I suspect that I'm probably doing forks on GitHub wrong, or at least I'm trying to use them in ways not envisioned by GitHub. In some cases I want to maintain copies of a GitHub repository for archival purposes (e.g., I'm afraid that the developer or GitHub will revoke public access to the repo), while in other cases, I want to institute a kind of code review process prior to merging upstream commits (e.g., I'm afraid of upstream doing something malicious). I will occasionally create branches in my forks, fix something, and send pull requests upstream, but I never feel like I need to maintain those forks---I'll happily delete branches or delete and re-create forks as needed.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#65

Post by Touche »

jasonlotito wrote: post #54
Touche wrote: post #43

Earlier quoted context omitted.

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

Clearly not enough, because you don't understand. You literally said that. How can you pass a judgement on something you don't understand?

Who said I'm passing judgment? I a lot of people prefer that workflow so I'm guessing there is some merit. I just don't understand it (I've never gotten an explanation that satisfies me).

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#66

Post by Touche »

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…

> 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".

I'm not following this at all... what is it you need from this tool and why?

> Does it matter that you had to implement 12 fixups at various points and rewrite the whole feature thrice after requirements changed? Probably not.

Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made. And having many small commits rather than 1 massive one makes it much easier to revert bad commits.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#67

Post by marssaxman »

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…

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, but I really can't imagine what that activity might be.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#68

Post by quantum_nerd »

ssmoot wrote: post #50
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 t…

nice reference to President Bush there at the end :) but I do agree, merging locally(when there are a ton of diffs/merge conflicts that I had to sift through) is still a cumbersome process.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#69

Post by marssaxman »

kevinmgranger wrote: post #18
StavrosK wrote: post #15

Earlier quoted context omitted.

What's wrong about what he said? Which step can you omit?

It's not that any of those steps can be omitted, it's that those steps overall are not difficult or complex.

Just last night I decided not to bother submitting a (tiny, one-line) patch to an open-source project because I didn't feel like going through all that rigmarole. The steps may not seem difficult or complex but they are steps, and they are friction, and eliminating friction is generally a good thing.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#70

Post by Touche »

marssaxman wrote: post #67
masklinn wrote: post #46

Earlier quoted context omitted.

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…

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 sort of feel the same way. The whole "prettiness" thing seems like a bit of a fetishism more than about productivity. Sort of like how people fetishize "inbox zero" (but in that case I do see the productivity gain).

I want my git history to be like my server logs, verbose. I can use tooling to reduce the noise and find what I need.

Post reply on HN