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

[Filipe Brandenburger]

Hi,

On Tue, Jun 2, 2015 at 7:58 AM, Dimitri John Ledkov
<dimitri.j.ledkov at intel.com> wrote:
> And I think this is _good_, because the submitter's commit ids will be
> preserved (together with the signed gpg commits) [...]

This, signed gpg commits, is actually the first reasonable argument I
see for merging and not rebasing commits.

TL;DR: GitHub model sucks, but I think we can live with it.

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

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.

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.

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

I think one model that helps is that of the "Commit Queue", in which
whenever a commit (or PR) is ready to be merged, it still goes through
a queue that tries to build it and possibly run some smoke tests to
ensure nothing is badly broken before actually merging it to git. Such
a system would most likely rebase, producing a linear history.

Oh, and I'm all for merges of feature branches, for an actual
*feature* as in something that takes >15 commits to implement and
needs to be developed in a separate branch. But those will most likely
be merged manually since I don't expect they won't have conflicts
anyways, so the PR merge feature of GitHub will be mostly useless
then...

Anyways, excuse the rant... I think we can live with GitHub and in the
end, everything will be alright :-)

Cheers,
Filipe