[Armchair observer...]
If any merges are allowed, they should be rare, have recent parent commits,
or the history graph becomes useless.
4. Each reviewed bug / feature must be rebased onto the current "known
good" commit, merged into a "probably good" commit, tested by build bots,
and only then
Tom Stellard via Openmp-dev writes:
> As part of the migration of LLVM's source code to github, we need to update
> our developer policy with instructions about how to interact with the new git
> repository. There are a lot of different topics we will need to discuss, but
> I would like to
A linear history makes it much easier to git-bisect, since each commit can be
rolled back individually. Easier cross-project bisection is one of the
advantages of having the monorepo, and I wouldn't want to loose that.
-- adrian
___
lldb-dev mailing
Hi,
As part of the migration of LLVM's source code to github, we need to update
our developer policy with instructions about how to interact with the new git
repository. There are a lot of different topics we will need to discuss, but
I would like to start by initiating a discussion about our
Reviving this old thread and +Joshua Peraza who's
also interested in this.
On Wed, Dec 13, 2017 at 4:17 PM Leonard Mosescu wrote:
> Thanks Greg,
>
> 1. Expose the opaque ptr as an opaque handle()
> - this is an easy, quick and convenient solution for many SBxxx types
> but it may not
Björn Pettersson A writes:
> In the new monorepo UC1 may or may not be a parent to UL1.
> We could actually have something like this:
>
> UL4->UC2->UL3->UL2->UL1->UL0->UC1
>
> Our DL1 commit should preferably have UL1 as parent after
> conversion
>
> UL4->UC2->UL3->UL2->UL1->UL0->UC1
>
He all,
I've updated the downstream fork zipping tool that I posted about last
November [1]. It is much improved in every way. The most important
enhancements are:
- Does a better job of simplifying history
- Handles nested submodules
- Will put non-submodule-update content in a subdirectory
On Mon, Jan 28, 2019 at 6:23 PM Bero Rosenkränzer
wrote:
>
> Hi,
> working without immediately obvious regressions on OpenMandriva x86-64, x86,
> aarch64 and armv7hnl.
> Since our 4.0 release is imminent, 8.0 won't go in there, but it will be our
> main compiler the day after the release and
Uploaded AArch64 binaries:
2c3bd3d686c3712ba5699e9a638bc849ddb0aae3
clang+llvm-8.0.0-rc1-aarch64-linux-gnu.tar.xz
Had one failure in check-all (memory sanitizer). I opened PR40511 for it [1].
I ran into some snags with ARM, I'm still figuring out if there's
something wrong with our
