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
Abandoning Gitflow and GitHub in favour of Gerrit
81–90 of 168 posts
Re: Abandoning Gitflow and GitHub in favour of Gerrit
#82I 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 complicated things, it's much more preferable to use a handful of related commits, all of which should get reviewed and merged as a batch. Does Gerrit not support this?
Re: Abandoning Gitflow and GitHub in favour of Gerrit
#83Earlier 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…
The argument made to me by a coworker (for why we should squish + rebase all PRs before merging) was that it makes it easier to use `git bisect` -- which is basically a binary search for Where a Bug was Added. In practice, I've never done this. I think it's that I work on a smaller codebase, or that I am 1/3 to 1/2 of the developers, and so it nearly always has seemed easier to read the code + tests, and poke at valu…
What's the issue with merge commits and git bisect?
Re: Abandoning Gitflow and GitHub in favour of Gerrit
#84Earlier quoted context omitted.
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).
You do, in your own comments. You pass judgement. Take for example this:
> The whole "prettiness" thing seems like a bit of a fetishism more than about productivity.
When you say:
> I've never gotten an explanation that satisfies me
You have gotten explanations, you just pass judgement on those explanations and assume they are based on a fetish. You effectively wave your hands and dismiss them.
So, you are passing judgement based on your own admitted ignorance. And you go out of your way to hinder any investigation you claim to perform.
Whatever. You suffer for your self-inflicted and self-admitted ignorance.
Re: Abandoning Gitflow and GitHub in favour of Gerrit
#85I 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…
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.
Re: Abandoning Gitflow and GitHub in favour of Gerrit
#86I 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…
With Gerrit you can chain up a series of dependent changes. The OpenStack Developer's Guide summarizes the workflow pretty well - http://docs.openstack.org/infra/manual/developers.html#addin....
The OpenStack community uses Gerrit pretty widely across our various projects. It might help to check out a busy project like Nova (https://review.openstack.org/#/q/project:openstack/nova,n,z) to get a feel for how Gerrit works in practice. Or a less-busy project like Bandit, which I'm involved in (https://review.openstack.org/#/q/project:openstack/bandit,n,...).
Re: Abandoning Gitflow and GitHub in favour of Gerrit
#87I 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'd suggest you take a look at phabricator too which has great code review and issue tracking. It does unfortunately still lack support for a first class notion of a patch series.
Re: Abandoning Gitflow and GitHub in favour of Gerrit
#88Earlier 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'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 commit history, you end up with a commit message like "fixing some issues based on comments" which affects at least 30% of the lines of code in the file. If I'm looking at that file 6 months after the fact, that commit message gives me no information about why those lines were added/changed.
With a clean history, you can use the same command and see the exact reason why a line of code was added through the commit message that added/changed it.
Re: Abandoning Gitflow and GitHub in favour of Gerrit
#89I 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…
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 it's showing the same revision on both sides.
Re: Abandoning Gitflow and GitHub in favour of Gerrit
#90I 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…
You can push up a series of commits, but each one is it's own code review so you want to do it less often. Another thing is if you have to add something to the HEAD^^ you have to rearrange your history and squash things together, but in the end the history is really clean. Also, each push of of each commit is versioned so you can easily tell what has changed between the last code review and the current; this is impossible with GitHub if you want to keep your history clean and compare different versions of the code review.