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

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 >

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

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

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

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

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

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

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

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

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

On 10/31/2018 03:02 PM, Justin Bogner wrote: > Tom Stellard <tstellar at redhat.com> writes: >>> On 10/31/2018 10:39 AM, Justin Bogner wrote: >>>> Tom Stellard <tstellar at redhat.com> writes: >>>>> On 10/31/2018 09:22 AM, Justin Bogner via llvm-dev wrote: >>>>>> Hi all, >>>>>> >>>>>> I've

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

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

On 22 Jul 2016, at 07:14, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Just tried to set it up there: https://github.com/joker-eph/llvm-unified > (git log —follow is working fine with this setup). > > While it preserves the history fine (I.e. the hashes are identical to the current git), it has a drawback: there isn’t anymore a common ancestor for the

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

On 10/11/2018 03:27 PM, James Y Knight via llvm-dev wrote: > TLDR: https://github.com/llvm-git-prototype/ exists as a read-only mirror of SVN, and is being updated continuously with a script running on an llvm-project AWS VM. > Hi James, What is the current status of the monorepo, have you resolved all the known issues with the history? Are there any other changes that need to be made

Hi, (bcc: mlir at tensorflow.org FYI) I am following-up on the integration of MLIR in LLVM as a subproject (Re: http://lists.llvm.org/pipermail/llvm-dev/2019-October/135687.html ). We're aiming to integrate into the monorepo next month. Right now our intent is for MLIR to live in a top-level directory in parallel to clang, lldb, lld, etc. Our top option for the integration is to perform a

On Fri, Nov 15, 2019 at 8:54 AM James Y Knight <jyknight at google.com> wrote: > > > On Fri, Nov 15, 2019 at 5:03 AM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> (bcc: mlir at tensorflow.org FYI) >> >> I am following-up on the integration of MLIR in LLVM as a subproject (Re: >>

On Wed, Dec 18, 2019 at 4:56 AM Peter Waller <Peter.Waller at arm.com> wrote: > On 17/12/2019 22:25, James Y Knight wrote: > > I think it would probably make the most sense to land this as a single > > merge-commit (from the 2700-commit rewritten history you've created) > > onto llvm-project master, rather than as 2700 individual toplevel > > commits to