similar to: Git Move: GitHub+modules proposal

Hi all, A short summary: Takumi has done 90% of the work here: https://github.com/llvm-project/llvm-project-submodule and I've been talking to GitHub, and here are the answers to my questions: > 1. How will the umbrella project's auto-increment hook work? Since the umbrella project cannot see the sub-modules' commits without some form of update, there are two ways to do this:

> On Jun 29, 2016, at 10:03 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > A short summary: Takumi has done 90% of the work here: > > https://github.com/llvm-project/llvm-project-submodule > > and I've been talking to GitHub, and here are the answers to my questions: > > >> 1. How will the umbrella

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

Now that we seem to be converging to an acceptable Git model, there was only one remaining doubt, and that's how the trigger to update a sequential ID will work. I've been in contact with GitHub folks, and this is in line with their suggestions... Given the nature of our project's repository structure, triggers in each repository can't just update their own sequential ID (like

> 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

> 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

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

On 27 June 2016 at 01:20, Matthias Braun <matze at braunis.de> wrote: > I really liked the the solution proposed earlier in this thread: Do nothing server side, but instead use > `git rev-list --count master` on the client side (which takes 0.9s on my machine) to get the number of the commit. So nothing to do on the ID part IMO. Mehdi replied to this proposal: "it does not help

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

It has also submodules. https://github.com/llvm-project/llvm-project-submodule Both llvm-project(-tree) and (-submodule) have refs/notes/commits. On Tue, Jun 28, 2016 at 1:13 AM Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 27 June 2016 at 17:03, Rafael Espíndola <rafael.espindola at gmail.com> > wrote: > > I think that trying to create a

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

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

> 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

I think that trying to create a ordering/rev number between independent git repositories is fundamentally unreliable. If we want to keep llvm and clang in lock step we should probably probably just have them in the same repository like https://github.com/llvm-project/llvm-project. Cheers, Rafael On Jun 27, 2016 11:10 AM, "Renato Golin" <renato.golin at linaro.org> wrote: > On

I personally find this email thread very hard to follow and read (this isn’t anyones fault.. its just a lot of replies). I am sure others do as well. I think it would be good to have a form/survey of some sort that can get feedback from users such as: who they are, how they use LLVM/contributions/etc, if they are pro-github move, how it impacts them, etc. People could then submit their feedback

> 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

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 >

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

On 28 June 2016 at 06:55, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > It has also submodules. > https://github.com/llvm-project/llvm-project-submodule > > Both llvm-project(-tree) and (-submodule) have refs/notes/commits. Nice! Can you try a server hook that will add an auto-increment number from submodules commits? cheers, --renato