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

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.

                      -David

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.

-eric

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190130/9d5ed83f/attachment.html>