[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits (original) (raw)

Justin Lebar via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 4 14:10:45 PST 2019

I'm also in favor of linear history, option #1.

FWIW I don't think lacking tight controls to prevent merges is going to be a huge deal. We already restrict who can commit, and there are lots of other rules you have to follow.

We might get an accidental merge or two every once in a while, but I expect we'll all be able to live with that?

On Wed, Jan 30, 2019 at 10:53 PM Mehdi AMINI via cfe-dev < cfe-dev at lists.llvm.org> wrote:

On Wed, Jan 30, 2019 at 1:19 PM Eric Christopher via cfe-dev <_ _cfe-dev at lists.llvm.org> wrote: On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > How about: > > > > Require a rebase, followed by git merge --no-ff > > > > This creates a linear history, but with extra null merge commits > > delimiting each related series of patches. > > > > I believe it is compatible with bisect. > > > > https://linuxhint.com/gitmergenoffoption/ > > We've done both and I personally prefer the strict linear history by a > lot. It's just much easier to understand a linear history. >

Agreed. Let's go with option #1.

What is the practical plan to enforce the lack of merges? When we looked into this GitHub would not support this unless also forcing every change to go through a pull request (i.e. no pre-receive hooks on direct push to master were possible). Did this change? Are we hoping to get support from GitHub on this? We may write this rule in the developer guide, but I fear it'll be hard to enforce in practice. -- Mehdi

cfe-dev mailing list cfe-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190204/58a8fff4/attachment.html>

More information about the llvm-dev mailing list