similar to: [monorepo] Downstream branch 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

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 >

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

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.

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

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

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

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”

> On 2016-Sep-18, at 09:51, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Folks, > > After feedback from Chris and Mehdi, I have added one long text answer > to *each* critical questions (impact on productivity), so that people > can extend their reasoning. > > But I have not made them compulsory, so that people that don't know > much

On 27 June 2016 at 15:39, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > So, I probably missed something, but what was the main objection to > just using submodules? This would put llvm inside clang instead of the > other way around. When changing an API one currently has to I don't think the consensus was to change the order of inclusion (llvm into clang), but to

So, It's been a while and the GitHub thread is officially dead, so I'll propose a development methodology based on the feedback from that thread. This is not *my* view, but all that was discussed in the threads. My objective is to form an official proposal to use Git as our main repository, overcoming all the problems we currently have without creating many others. In the end, I think

> On Oct 13, 2016, at 2:15 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Oct 13, 2016, at 1:40 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com <mailto:dexonsmith at apple.com>> wrote: >> >>> >>> On 2016-Oct-13, at 11:23, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at

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

>> As for updating the meta repository: We could disable write access for the normal llvm developer and delegate the submodule bumping to an external >> server. I believe this would be an easy enough job for buildbot or jenkins. > > The plan is to disable all write access to this repository (otherwise > we'll create a nightmare). Having an external counter could be >

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

> 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

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

> 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 Oct 13, 2016, at 11:03 AM, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > | 6. How important is cross-project blame, grep, etc.? >   <> > I don't understand "cross-project blame" as it works on one file at a time? True, not straightforward blame. My workflow when trying to track the history of some code involves frequently