Hi, On Tue, Jun 2, 2015 at 7:58 AM, Dimitri John Ledkov <dimitri.j.led...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
