[systemd-devel] [ANNOUNCE] Git development moved to github

[Suckow, Thomas J]

On 6/3/15, 7:14 AM, "Filipe Brandenburger" <filbranden at google.com> wrote:

>
>I think, though, in general, the "GitHub way" of focusing on PRs and
>not commits tends to generate poorer git commits and git histories in
>general. I too often see broken PRs being ammended with second or
>third commits to fix the bugs, which makes git bisect hit and miss in
>lots of projects.

It is what the project makes it. If the project demands people to rewrite
the PR history instead of tacking on fix commits, then this problem is
avoided.


>And many projects have commit descriptions that are
>totally meaningless (that's not just a GitHub thing, but I think
>GitHub makes it a lot easier to get sloppy on those.)

The project is responsible for enforcing quality. If a project has a lazy
maintainer, the project will reflect it.

>I actually think who gets it right is Gerrit which is focused on
>individual commits and not in PRs with sets of commits. Even if you
>upload 3 or 4 commits in a row, they'll be reviewed one by one and
>submitted as they're approved. It's easy to merge the first two but
>send the last two back for rework. With GitHub, you'd have to do that
>manually. I'm not saying Gerrit is perfect, far from it, but I think
>at least they got it right in being commit-centric rather than
>PR-centric.

I use Gerrit at work and Github at home. You can be hard nosed about it
either way. I actually find Gerrit more trouble in the sense that people
who are not comfortable with Git can really screw up Gerrit and make it
tedious to abandon a bunch of commits. On github a force push usually
makes all badness a figment of your imagination. Maybe it is just work
though, it is much easier to be hard nosed to strangers.

>
>GitHub also makes it hard to look at the individual commits and commit
>messages. By default, they just give you the blurb the author typed on
>the PR description (which ends up nowhere in git) and show you a
>consolidated diff for the whole PR, so it's quite possible that the
>first commit in the series doesn't even compile and you won't really
>get to know about that as you merge it. I always make a point to first
>thing reviewing a PR go to the "commits" tab and look at each commit
>on its own, most of the time I don't even look at the consolidated
>diff since I think it's mostly meaningless.

As you should IMO.

>I'm of course counting on our maintainers here to make a good job of
>weeding out bad commits.

A good project starts with good maintainers. Long live good maintainers.

-
Thomas