similar to: RFC: Dealing with out of tree changes and the LLVM git monorepo

Based on the feedback so far, I propose that we call this discussion done -- we will not go with this zippered proposal, but will proceed with https://github.com/llvm-git-prototype/llvm/. On Thu, Nov 15, 2018 at 5:06 PM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > What is the status

I don't feel like I can unilaterally declare this topic closed, since there was an objection to that last time. But with no additional feedback after another week, I'd still really like to close this out, and start moving forward with the original plan, again... On Mon, Nov 26, 2018 at 2:28 PM James Y Knight <jyknight at google.com> wrote: > It's been a week and a half more

Yes, I’m still trying to evaluate the migration script’s downsides as compared to the zipper approach’s downsides. Sorry that I got a little held up, but I have to balance evaluating this with getting other work done. I should have some feedback to a few of the responses on this thread next week. I really don’t think I can respond in a useful/productive way before I’ve finished these

Justin Bogner <mail at justinbogner.com> writes: > I'll write up some more detailed docs on this, but all you need to do is > a subtree merge to one of the zippered commits. This will then prevent git-biisect from working properly, unfortunately. Maybe most people don't need it be we should be aware of and communicate the tradeoffs. > If you want a monorepo view for all

Hi, Thanks for starting this discussion Justin! On 10/31/18 5:22 PM, Justin Bogner via llvm-dev wrote: > Hi all, > > I've spent some time in the last couple of days trying to figure out how > to adopt the [LLVM git monorepo prototype] for an out of tree backend. > TLDR: I'm not convinced that this prototype is the right approach to > converting to the monorepo, and I

Mehdi AMINI <joker.eph at gmail.com> writes: > > If you want a monorepo view for all of your branches' histories > > too it's more involved, but I'm not sure anyone really needs > > that. In any case, even if someone does want that the nature of > > the zipper approach means it could be done later > > non-destructively. >

Thanks for writing this up. I think it's a really important point which deserves discussion. Ultimately, I think it is a question as to whether to prioritize the easy switchover for existing out of tree forks, or to prioritize having the best conversion we can make. I feel very strongly that the latter should be the priority for the official repository conversion, and that, therefore, we

I just want to point out that the issue of incompatible history is not new. This has been getting discussed all the way back in July 2016. http://lists.llvm.org/pipermail/llvm-dev/2016-July/102657.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/102657.html> As James said in that email: > That we'll be getting incompatible history has been glossed over, and it is >

Justin Bogner via llvm-dev <llvm-dev at lists.llvm.org> writes: > The layout here is not at all different, only the process by which the > repo is generated. I strongly believe that a history preserving > conversion is very important if we want to avoid making porting > out-of-tree work horribly disruptive. How would an out-of-tree branch be ported with this new approach? Do

On Fri, Nov 2, 2018 at 2:11 PM Justin Bogner <mail at justinbogner.com> wrote: > James Y Knight <jyknight at google.com> writes: > > Thanks for writing this up. I think it's a really important point which > > deserves discussion. > > > > Ultimately, I think it is a question as to whether to prioritize the easy > > switchover for existing out of

Mehdi AMINI <joker.eph at gmail.com> writes: > Yes, but that's the case for the zipper repo anyway: one merge per > commit. The point is that the second commit is just a trivial merge, > it wouldn't show up in a file `git log` for example. > In the linear rewritten monorepo, adding the history taken from the > existing git mirror would lead to duplicated commits, as

Well shoot, you beat me to it. :) I've been working on a similar tool but it's not ready yet. Looking forward to trying yours! -David James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes: > I'm about to post exactly this tool -- I've been testing it on the > CHERI forks of llvm/clang/lld (lots of history and merges and stuff

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

Hi James, I've started working with the prototype layout in context of Google's internal infrastructure. With deep apologies, I have a (very late, I know) pair of requests that have only recently solidified for me. 1. Could you add annotated tags after the cut point of each release? (I think this would probably be easy.) 2. Could you mark branch/tag operations somehow other than a

On Fri, 16 Nov 2018 at 00:35, Bruce Hoult <brucehoult at sifive.com> wrote: > Yes, I'd expect only a tiny fraction of commits to change the interface between say, clang and llvm in an incompatible way, but where they do it's essential to get both sides at the same time if you want to to have every commit buildable for things such as bisection or incremental rebasing (as I think

On Fri, 16 Nov 2018 at 00:09, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The original svn has atomic commits across all projects. It would be crazy to use a git version that doesn't duplicate that. I thought someone found that only a tiny fraction of commits actually made use of that. It's definitely not something anyone can rely on, so I'd consider it

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 Nov 15, 2019, at 1:52 AM, Alex Denisov <1101.debian at gmail.com> wrote: > >> I think I can just get the patch and remove the `llvm` on top of the paths, but that’s not a scalable approach. > > IIRC, the -p option of 'patch' is exactly for doing this. Would that simplify your use-case? > Yes, for a single patch that would work. If there is a way to do

On Fri, Nov 16, 2018 at 4:04 PM NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Hello, David. > > On Sat, Nov 17, 2018 at 7:46 AM David Jones via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi James, >> >> I've started working with the prototype layout in context of Google's >> internal infrastructure. With deep apologies, I

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 >