[lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits
Justin Lebar via lldb-dev
lldb-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/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.
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev