search for: subrepository

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-r...

james woodyatt <jhw at conjury.org> writes: > p.s. The Mercurial subrepositories feature is loads better than git > submodules and it's built into the tool. But never mind that. Just go > with Git and don't look back. Nobody ever got fired for buying from > the market leader. I don't use submodules enough to be a good juge, but my understanding is that Git's

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

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

On Aug 18, 2011, at 10:57 AM, David Greene wrote: > > Did the project ever come to a decision about making a transition to > git? I'm trying to do some longer-term planning and it would be helpful > to know what the roadmap is. Me too. I've been catching up on the thread from a couple weeks ago, and I didn't see any clear conclusion. I have some comments about the

Did the project ever come to a decision about making a transition to git? I'm trying to do some longer-term planning and it would be helpful to know what the roadmap is. Thanks! -Dave

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

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

>> 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 read-write consumers of the sub-projects being included should count for a lot I agree. > as a read-write

> 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

> On Jul 28, 2016, at 2:07 PM, Justin Lebar <jlebar at google.com> wrote: > > Chris, > > What I notice in your latest e-mail -- and I don't know if this is > intentional, so sorry if I'm reading too much into it -- is that the > language has switched from "an unwarranted and unacceptable burden" to > "a burden”: I consider it unwarranted and

> Running the same 'git checkout' commands on multiple repos has always been sufficient to manage the multiple repos so far Huh. It definitely hasn't worked well for me. Here's the issue I face every day. I may be working on (unrelated) changes to clang and llvm. I update my llvm tree (say I checked in a patch, or I want to pull in changes someone else has checked in). Now

> 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

Subject kinda says it all. Here is my rationale: The test-suite is really weird relative to the rest of the LLVM project: 1) It contains all manner of crazily licensed code. 2) We don't really care about the history at all. Any concerns around linear history or bisection are pretty much irrelevant. 3) We don't ever plan to have LLVM code move into or out from the test-suite 4) Its already

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