similar to: Adding the LLVM license file to the monorepo root

Displaying 20 results from an estimated 10000 matches similar to: "Adding the LLVM license file to the monorepo root"

2019 Jul 17
4
[RFC] change .gitignore for monorepo
James, we are using an *unmodified* llvm-project (master llorg), and just add some extra projects from our internal repos to the top-level. Thanks, Slava From: James Y Knight [mailto:jyknight at google.com] Sent: Wednesday, July 17, 2019 11:19 AM To: Zakharin, Vyacheslav P <vyacheslav.p.zakharin at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC]
2019 Nov 14
4
LLVM projects and monorepo.
Hello, I am trying to access https://git.llvm.org/git/llvm to be able to cherry pick some of the recent commits I did in the monorepo into our downstream llvm-only repository. The host seems defunct, is this part of the move to the monorepo? I think I can just get the patch and remove the `llvm` on top of the paths, but that’s not a scalable approach. Francesco
2018 Nov 05
2
RFC: Dealing with out of tree changes and the LLVM git monorepo
Well shoot, you beat me to it. :) I've been working on a similar tool but it's not ready yet. Looking forward to trying yours! -David James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes: > I'm about to post exactly this tool -- I've been testing it on the > CHERI forks of llvm/clang/lld (lots of history and merges and stuff
2018 Nov 05
2
RFC: Dealing with out of tree changes and the LLVM git monorepo
Mehdi AMINI <joker.eph at gmail.com> writes: > > If you want a monorepo view for all of your branches' histories > > too it's more involved, but I'm not sure anyone really needs > > that. In any case, even if someone does want that the nature of > > the zipper approach means it could be done later > > non-destructively. >
2018 Nov 05
2
RFC: Dealing with out of tree changes and the LLVM git monorepo
Mehdi AMINI <joker.eph at gmail.com> writes: > Yes, but that's the case for the zipper repo anyway: one merge per > commit. The point is that the second commit is just a trivial merge, > it wouldn't show up in a file `git log` for example. > In the linear rewritten monorepo, adding the history taken from the > existing git mirror would lead to duplicated commits, as
2019 Jan 29
2
[monorepo] Much improved downstream zipping tool available
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 of the monorepo - Updates tags In addition there are plenty of the requisite bug fixes. The
2019 Jan 29
2
[monorepo] Much improved downstream zipping tool available
Björn Pettersson A <bjorn.a.pettersson at ericsson.com> 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 >
2018 Nov 12
2
[monorepo] Downstream branch zipping tool available
Building on the great work that James Knight did on migrate-downstream-fork.py (Thanks, James!) [1], I've created a simple tool to take migrated downstream fork branches and zip them into a single history given a history containing submodule updates of subprojects [2]. With migrate-downstream-fork.py, one is left with a set of unrelated histories, one per subproject: llvm
2019 Jan 30
2
[monorepo] Much improved downstream zipping tool available
Björn Pettersson A <bjorn.a.pettersson at ericsson.com> writes: > In llvm (split) we have: > > UL4->UL3->UL2->UL1->UL0 > \ > ...->DL2->DL1 > > In clang (split) we have: > > UC4->UC3->UC2->UC1->UC0 > \ > ...->DC2->DC1 > > > DL1 is a commit that updates the
2018 Nov 02
2
RFC: Dealing with out of tree changes and the LLVM git monorepo
Justin Bogner <mail at justinbogner.com> writes: > I'll write up some more detailed docs on this, but all you need to do is > a subtree merge to one of the zippered commits. This will then prevent git-biisect from working properly, unfortunately. Maybe most people don't need it be we should be aware of and communicate the tradeoffs. > If you want a monorepo view for all
2018 Nov 01
2
RFC: Dealing with out of tree changes and the LLVM git monorepo
I just want to point out that the issue of incompatible history is not new. This has been getting discussed all the way back in July 2016. http://lists.llvm.org/pipermail/llvm-dev/2016-July/102657.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/102657.html> As James said in that email: > That we'll be getting incompatible history has been glossed over, and it is >
2017 May 09
2
Add more projects into Git monorepo
On 9 May 2017, at 15:58, Mehdi AMINI <joker.eph at gmail.com> wrote: > I'd expect any CI system to be able to cache this. > Also if you're issue is archiving a lot of build artifacts, the constant cost of the checkout isn't gonna matter that much. > Finally, the read-only individual repo can still be used by CI, which address this entirely. If we want to pull in new
2019 Nov 15
3
MLIR landing in the monorepo
On Fri, Nov 15, 2019 at 8:54 AM James Y Knight <jyknight at google.com> wrote: > > > On Fri, Nov 15, 2019 at 5:03 AM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> (bcc: mlir at tensorflow.org FYI) >> >> I am following-up on the integration of MLIR in LLVM as a subproject (Re: >>
2016 Jul 26
4
[RFC] One or many git repositories?
>> 3. For many (most?) developers, changing to a monolithic git repo is a >> *bigger* workflow change than switching to separate git repos. Many >> people (and at least some downstream infrastructure) use the git >> mirrors exclusively, aside from git-svn for committing. >> >> I believe the idea is to continue to maintain the read-only independent >> git
2017 May 09
2
Add more projects into Git monorepo
On 8 May 2017, at 20:51, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 2017-05-07 1:01 GMT-07:00 David Chisnall via llvm-dev <llvm-dev at lists.llvm.org>: > Is this intended to be the monorepo that eventually becomes the official repo, because if so I strongly object to putting libunwind, libc++ and libc++abi in it. I have recently been working on bring-up for libc++
2019 Nov 15
2
LLVM projects and monorepo.
> On Nov 15, 2019, at 1:52 AM, Alex Denisov <1101.debian at gmail.com> wrote: > >> I think I can just get the patch and remove the `llvm` on top of the paths, but that’s not a scalable approach. > > IIRC, the -p option of 'patch' is exactly for doing this. Would that simplify your use-case? > Yes, for a single patch that would work. If there is a way to do
2019 Jul 17
6
[RFC] change .gitignore for monorepo
Hello, My team is using some non-llvm projects along with llvm-project monorepo. The projects are checked out to the top level of llvm-project, and 'git status' would complain about them unless we add them to .gitignore. We do not really want to change llorg's .gitignore on our side, so may we propose changing llorg's .gitignore to ignore all top-level files/directories that are
2016 Jul 29
0
[RFC] One or many git repositories?
I don’t know what you mean by dealing with the merging, I don’t expect any difficulties, you need to elaborate. What I don’t see you addressing here is why this should be more of a problem in the monorepo case (as it was implied in the email I was answering to). Your answer made it sound like you thought the monorepo would solve all downstream problems ("I don't know what you mean… I
2016 Oct 13
2
GitHub Survey?
> On 2016-Oct-13, at 11:23, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi, > > Thanks a lot Duncan, I really like this! I totally support adopting this scheme now. See inline a few quite minor comments. > > Renato: are you still interested and available now to set-up the survey? We should close on this *this week*. > > >> On Oct 12, 2016, at 7:07
2020 Jan 15
3
Flang landing in the monorepo - next Monday!
Hi Eric, Renato Thanks again for the engagement and challenge on this, it is really useful feedback to know what we need to do to get F18 into the project in a way that everyone is happy with. I have tried to give timelines on the points addressed below where I can today. Clearly we need to do some work on points 8-11, but are the above plans/answers to points 1-7 sufficient at this stage and