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
On 1 Feb 2019, at 22:48, Peter Wu via cfe-dev wrote:
>
> On caveat is that the test coverage would be limited or else the build
> times would be very long. There are quite some builders for various
> projects (llvm, cfe, compiler-rt, etc.) on a lot of different platforms
> and targets (Linux,
> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Peter
> Wu via cfe-dev
> Sent: Friday, February 01, 2019 5:49 PM
> To: Arthur O'Dwyer
> Cc: llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; openmp-
> d...@lists.llvm.org; lldb-dev@lists.llvm.org
>
Oh, I'm completely in favor of making bad commits much less likely. I
simply think there is a decent solution between "let everything in" and
"don't let everything in unless its proven to work everywhere" that gets
90% of the improvement. The complexity of guaranteeing a buildable
branch is
> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of David
> Greene via cfe-dev
> Sent: Thursday, January 31, 2019 4:56 PM
> To: Roman Lebedev
> Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev
> Subject: Re: [cfe-dev]
I realise that llvm trunk can move fairly quickly.
So my original, but brief, suggestion was to merge the current set of
approved patches together rather than attempting them one at a time.
Build on a set of fast smoke test bots. If something breaks, it should be
possible to bisect it to reject a
Roman Lebedev writes:
> *Does* LLVM want to switch from phabricator to github pr's?
> I personally don't recall previous discussions.
> Personally, i hope not, i hope phabricator should/will stay.
I find Phab pretty unintuitive. I just started using it in earnest
about four months ago, so
writes:
> Systems that I've seen will funnel all submitted PRs into a single queue
> which *does* guarantee that the trial builds are against HEAD and there
> are no "later commits" that can screw it up. If the trial build passes,
> the PR goes in and becomes the new HEAD.
The downside of a
Mehdi AMINI writes:
> 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
>
> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of David
> Greene via cfe-dev
> Sent: Wednesday, January 30, 2019 3:52 PM
> To: Jeremy Lakeman
> Cc: llvm-dev; LLDB Dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org)
> Subject: Re: [cfe-dev]
On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev
wrote:
>
> Bruce Hoult via llvm-dev 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.
>
11 matches
Mail list logo
