[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits
Mehdi AMINI via llvm-dev
llvm-dev at lists.llvm.org
Fri Feb 1 21:27:18 PST 2019
On Fri, Feb 1, 2019 at 4:44 PM Tom Stellard <tstellar at redhat.com> wrote:
> On 01/30/2019 10:53 PM, Mehdi AMINI via llvm-dev wrote:
> > On Wed, Jan 30, 2019 at 1:19 PM Eric Christopher via cfe-dev <
> cfe-dev at lists.llvm.org <mailto: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 <mailto:cfe-dev at lists.llvm.org>> wrote:
> > >
> > > Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org <mailto:
> 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?
> No enforcement plan at this point, but I was planning to contact github
> about this to
> see what options we had. Last time you looked into it, did you talk to
> anyone at github
Yes, and they pointed to the web hooks they have (but these are only
post-commit I believe) and they pointed to the pull-request policy to
enforce this. They said they wasn't any other option (at the time).
If a custom pre-receive hook is out of the realm of possible, maybe they
could add as a new "branch protection" setting that would "enforce linear
history" on a branch. This seems like a reasonable feature that other
people may want.
> This is also why I think it's important to decide early so we have time to
> look at
> what our options are to enforce these policies. If pull requests are our
> option for enforcement, then I think it would be good to know that before
> have a large debate about Phabricator vs Pull Requests.
If we use pull-request as a tool for ensuring linear history, we don't
*have to* do the reviews there: it would be possible to continue doing the
reviews on the mailing list and on Phabricator, and just open a PR after
approval to use the "Rebase and merge" to get the change in immediately.
I'm not sure the "not do any review on the pull request" while having to
open a PR for any change anyway will be practical though, at this point
folks may just naturally start reviewing there directly.
Another idea I floated around is to force to use `git llvm-push` instead of
`git push` and have it check that no merge is about the be pushed. We could
prevent direct use of `git push` by using this "branch protection" feature:
https://help.github.com/articles/about-required-status-checks/ ; we'd have
`git llvm-push` whitelisting the commit before actually pushing it.
> > We may write this rule in the developer guide, but I fear it'll be hard
> to enforce in practice.
> > Mehdi
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev