We actually support linear landing in homu, however since github has no way of automarking PRs as "merged" through the API (it only works if the PR actually merged), the support is a bit flaky (it will edit the PR title to say [merged] and close it). I hope this changes soon.
I personally prefer having the merge commit since it makes bisects more reliable. Each merge commit is "known good", so bisecting over all merge commits will make it possible to find broken PRs without false positives coming in the way*. We try to ensure that no individual commit will fail to build, but we don't test this on automation so there can always be build/test failures hidden within the set of commits from a PR. In a linear model these will cause problems unless we start testing on every commit (which is unlikely). Another reason I prefer merge commits is that it becomes very easy to hunt down which PR caused a bug (after using blame or pickaxe). This can be done by opening the commit in github too, but that feature doesn't always work. Finding PRs from commits is something I find myself doing a lot more than bisecting. This can be overcome using a dummy linear "merge commit" with PR info, however. (These aren't really strong preferences. I am okay with linear history too) As far as syncing is concerned AIUI we can still sync after flattening the history. But yeah, it's not ideal. *Admittedly this is a bit fiddly to do with git, requires some use of rev-list and skip. But it's possible; I recall doing this once. Thanks, -Manish Goregaokar On Tue, Apr 26, 2016 at 11:50 PM, Gregory Szorc <g...@mozilla.com> wrote: > Servo developers, > > I noticed that Servo and a number of other Servo related Git repos have > tons of merge commits. This is the Git[Hub] way after all: create a merge > commit for every pull request. > > The thing is, I'm not a huge fan of merge commits in version control, > especially for large projects. I like having simple, linear history where > any commit you land on is "good," can be built, and bisected on. This is > more or less what we do in mozilla-central (ignore the merge commits for > the integration repos - those were a necessary evil to deal with scaling > issues 4+ years ago and are going away). There are other reasons to avoid > merge commits too. See the giant wall of text I wrote in bug 1266863 on the > subject. > > Thinking forward to a day when we start vendoring more Rust/Servo > components into mozilla-central and the VCS "syncing" complications that > arise from it, I would much rather be dealing with Servo repos with linear > history because well, linear is simpler than the DAG spiderweb that merge > commits produce (run `gitk` on the Servo repo to see what I'm talking > about). > > May I propose Servo change its landing bot to rebase commits instead of > merging them so that the repo history be linear so all the complexities > around merge commits can go away? > > FWIW, other VCS hosting and landing services (like Gitlab and MozReview) > have a button that rebases instead of merges for landings. Furthermore, > Facebook rebases on many of their GitHub projects (they don't use the > buttons/APIs on GitHub). So there is definitely precedence for rebasing > instead of merging. > > Obviously you can't force every random Rust project on GitHub to adopt a > linear commit model. All I'm asking is that Servo and its immediately > related projects consider changing their ways. Who knows, perhaps by doing > so you'll help convince GitHub that there are valid use cases for linear > repos and they'll support rebasing in their web UI. At the rate they are > copying good ideas from Gitlab and other hosting providers, I wouldn't be > surprised if they were already considering it :) > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
