similar to: alternative to "script/plugin install -x" that works with git

Hi, > On Sep 7, 2016, at 10:30 AM, dag at cray.com wrote: > > Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Right, we actually have a proposal to take what is in the current SVN >> repo here: http://llvm.org/svn/llvm-project/ and migrate this to a >> single repository. >> I was not sure if you were referring to this proposal

Dear all, I would like to (re-)open a discussion on the following specific question: Assuming we are moving the llvm project to git, should we a) use multiple git repositories, linked together as subrepositories of an umbrella repo, or b) use a single git repository for most llvm subprojects. The current proposal assembled by Renato follows option (a), but I think option (b) will be

I have one reasone why we should not moe to monolithic repository - If you do some light stuff like clang-tidy, that don't often require syncing with clang, but you still want to have the most recent checks, then I don't see a solution in monolithic repository. And this is a real issue if you only have 2 or 4 core laptop to do work. And I guess the the build system won't solve the

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

> On Jul 28, 2016, at 12:05 PM, Justin Lebar <jlebar at google.com> wrote: > >>> The decision of whether or not to include these projects >>> affects only read-write consumers of these projects -- of which there >>> are relatively few people. >> >> Maybe there are few, but the impact is non-insignificant. Also I think the opinions of the

Hi Mehdi, I really like your idea of having a few "projected" git repositories (i.e. capture all commits that touch llvm/ into llvm.git, all that touch clang/ to clang.git etc.). I think it should solve our problem of llvm-forks-with-downstream changes very nicely (I think we won't have to do anything, as you said). I still want to sleep on it to see if I can spot any issues.

The build system can help, you just need to have two (sparse) checkout: one for LLVM/clang and the other for clang-tidy, and configure the build with the LLVM/clang checkout adding the clang-tidy as external. — Mehdi > On Jul 22, 2016, at 1:22 PM, Piotr Padlewski via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > And the same thing happen to IDEs - I would not like to spend

> On Jun 2, 2016, at 11:22 AM, dag at cray.com wrote: > > Matthias Braun via cfe-dev <cfe-dev at lists.llvm.org> writes: > >> 3. Make sure we have ala llvm-project-submodules setup in the official >> account. (Optional or necessary for the buildbots?) > >> 7. Make sure bisecting with llvm-project-submodules is a good experience > > I would like to

> On Jul 22, 2016, at 1:16 AM, Simon Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Ill start by saying Ive skimmed this thread and am not actually a user of LLVM at all, but had some git thoughts that might be worth contributing. > >> On 22 Jul 2016, at 01:16, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>

> On Jul 28, 2016, at 10:53 AM, Justin Lebar <jlebar at google.com> wrote: > > Thanks again for your thoughts, Chris. > >> As a straw man I would suggest the following criteria for inclusion into the mono-repo: >> >> (1) Projects in the mono-repo must be tightly coupled to specific versions or commits of other projects in the mono-repo > > I'm fine

On Wed, Jul 20, 2016 at 5:02 PM Justin Bogner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org> writes: > > I would like to (re-)open a discussion on the following specific > question: > > > > Assuming we are moving the llvm project to git, should we > > a) use multiple git repositories, linked

I think it is erroneous to have the subrepository projects and tools listed in .gitignore. Instead of being ignored, methinks they should be listed as submodules in .gitmodules: [submodule "tools/clang"] path = tools/clang url = ../clang.git [submodule "projects/compiler-rt"] path = projects/compiler-rt url = ../compiler-rt.git [submodule

Sent from my iPhone > On Sep 8, 2016, at 11:08 AM, dag at cray.com wrote: > > Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> First, have you read this document: https://reviews.llvm.org/D24167 ? >> >> TLDR: The answer is no: you have to see it as it is today, i.e. a >> single SVN repo containing all the sub-projects, and “exports”

Hi Duncan, > […] > 2. Those working on projects *outside* the monolithic repo will get the downsides of both: a monolithic repo that they are only using parts of, and multiple repos that are somehow version-locked. > > 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

> > Message: 2 > Date: Thu, 29 May 2008 06:35:01 -0700 > From: David Chelimsky <dchelimsky at gmail.com> > Subject: Re: [rspec-users] Coloured output in rspec 1.1.4 > To: rspec-users at rubyforge.org > Message-ID: <175B70FE-B706-4C03-8B20-C5B207268AD6 at gmail.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > On May 29, 2008,

I have a sub-application project that I had previously converted to edge rails under svn. Originally, vendor/rails was set up with svn:externals so that an svn update at the project''s root would pull the latest trunk along with all the other updates. Since Rails has moved to GiT and depreciated svn I decided to remove the svn:externals reference for vendor/rails and reinstall trunk using

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

Hi there, I''ve been trying for a few hours now to get RoR and postgresql talking - but I''m very confused about what''s going on (I''m running windows btw). I haven''t created a database in postgresql (I''m assuming that RoR will do that?) my database.yml looks like this: production: adapter: ruby-postgres database: rails_production

> The only thing a monorepo gets you that strictly isn’t possible without > it is the ability to commit to multiple projects in a single commit. > Personally I don’t think that is a big enough justification, but that is > my opinion, not a fact. Okay, I just bumped into r277008, in which commits to llvm, clang, and clang-tools-extra all have the same SVN revision number. I don't

From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Thursday, June 30, 2016 4:15 PM To: Robinson, Paul Cc: Clang Dev; LLDB Dev; LLVM Dev; Reid Kleckner; llvm-foundation at lists.llvm.org Subject: RE: [cfe-dev] [lldb-dev] [llvm-dev] Sequential ID Git hook On 30 Jun 2016 10:20 p.m., "Robinson, Paul" <paul.robinson at sony.com> wrote: > We've since stopped creating