[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits

[Justin Lebar via llvm-dev]

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/git_merge_noff_option/
>> >
>> > 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>