David Greene via llvm-dev
2019-Jan-30 20:42 UTC
[llvm-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
Eric Christopher via llvm-dev
2019-Jan-30 21:18 UTC
[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits
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
Mehdi AMINI via llvm-dev
2019-Jan-31 06:53 UTC
[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits
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>