search for: subrepositori

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

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

...in 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 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 significantly simpler and more effective. > > Moreover, I think t...

...in 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 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 significantly simpler and more effective. > > Moreover, I think t...

...you picked Mercurial over Git, but we're going to be *greatly* outnumbered by the Git users who would scream bloody murder if you picked Mercurial instead. In closing, just go with Git and tell people who don't like it to use Mercurial and Hg-git. We're adaptable. 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. -- j h woodyatt <jhw at conjury.org>

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 significantly simpler and more effective. Moreover, I think the issues raised with option (b) are either incorrect or ca...

...t; llvm-dev at lists.llvm.org> wrote: > >> 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 significantly simpler and more effective. >> Moreover, I think the iss...

...lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > 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 significantly simpler and more effective. > Moreover, I think the issues raised with option...

...mit to the multirepo would not be able to translate cross-cutting commits into a single commit in the umbrella repository without cooperation from the script that translates commits to the multirepos into commits in the umbrella repository (that's the one that contains all the multirepos as git subrepositories). It's possible -- it's turing complete --, but it would be very complicated. Still more complicated would be writing a script that would allow monorepo users to push to putative try bots that are based off the multirepo. Again anything is possible, but I have written and maintained si...

...would not be able to translate cross-cutting commits into a single > commit in the umbrella repository without cooperation from the script > that translates commits to the multirepos into commits in the umbrella > repository (that's the one that contains all the multirepos as git > subrepositories). It's possible -- it's turing complete --, but it > would be very complicated. > > Still more complicated would be writing a script that would allow > monorepo users to push to putative try bots that are based off the > multirepo. Again anything is possible, but I have...

...le to translate cross-cutting commits into a single >> commit in the umbrella repository without cooperation from the script >> that translates commits to the multirepos into commits in the umbrella >> repository (that's the one that contains all the multirepos as git >> subrepositories). It's possible -- it's turing complete --, but it >> would be very complicated. >> >> Still more complicated would be writing a script that would allow >> monorepo users to push to putative try bots that are based off the >> multirepo. Again anything is p...

...sts.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 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 significantly simpler and more...

> 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