similar to: [RFC] One or many git repositories?

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

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

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

> 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

By the way, I've been using the existing read-only monorepo [1] for a few days now. The intent is to commit via the script I put together [2], although I haven't committed anything other than a testing commit [3]. All I can say is, *wow* is it nice. I hid everything I don't care about using a sparse checkout [4]. Many of my tools (e.g. ctrl-p [5] [6], ycm [7]) suddenly work better

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

On Wed, Jul 20, 2016 at 6:26 PM, Justin Bogner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Justin Lebar <jlebar at google.com> writes: > >> 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. > >

> And if it is, then the "only thing a monorepo gets you" isn't something that you need a monorepo to get. This is an *extremely important* point to understand, so let me try to be really clear about the current state of the world and the state of the world under the two "move to git" proposals. Today, all commits ultimately end up in SVN. Our SVN is a effectively a

> 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

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.

One other point about maintaining branches: With the single repository approach, maintaining a long-running branch that touches multiple subprojects (e.g. llvm and clang) becomes *far* simpler. With the umbrella repo, you have to do the submodules trickery I described in the original e-mail. It is complicated, and takes a lot of typing (or requires you to develop custom scripts). But with the

> 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: >>

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

> -----Original Message----- > From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] > Sent: Thursday, July 21, 2016 3:16 PM > To: Robinson, Paul > Cc: Renato Golin; Justin Lebar; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] One or many git repositories? > > > > On Jul 21, 2016, at 2:33 PM, Robinson, Paul via llvm-dev <llvm- > dev at

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

I wanted to present some of the particular reasons why I'm pretty strongly opposed to a purely flat layout of projects the way the current github 'llvm-project' repository looks, as that hasn't happened on the list yet. I'm replying to myself as I don't see a much better place to hang that conversation. On Wed, Jul 20, 2016 at 7:38 PM Chandler Carruth <chandlerc at

Can you please clarify your use of “cost” (bandwidth, disk space, extra command to type initially?), Developer time, barrier to entry for new contributors. Getting the sparse-checkout business right looks like it is actually non-trivial and not recommended for the git novice. *Changing* the sparse-checkout configuration later appears to be fraught with peril (easy to get wrong). The claim is

On 30 Jun 2016 10:20 p.m., "Robinson, Paul" <paul.robinson at sony.com> wrote: > We've since stopped creating the tags, and gotten used to not having > them. We do the 'rev-list --count' trick which mainly gets recorded as > one component of the version number, and it has been working for us. Does that work for sub modules inside the umbrella project? How