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: >> 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. >> > > Sounds right. > > >> Our top option for the integration is to perform a git subtree merge to >> bring the MLIR history into the monorepo, here is a prototype: >> https://github.com/joker-eph/llvm-project-with-mlir >> > > I'll note that this would be the very-first merge commit on master. I'm > not opposed to this, but others may be. (To allow this, we'd temporarily > reconfigure github to allow pushing merge-commits, for this one commit, and > then disable it again.) > > However, another issue is that subtree merges have really weird artifacts > when trying to look through history, with e.g. git log <filename>. I think > I'd really prefer to avoid utilizing a subtree-merge for this. >Right: `git blame` work well though. The alternative would be to have a commit to move the files under a “mlir” directory and then do a normal merge? I am interested to hear about other advices here :) Thanks, Mehdi>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/d6f2c7b1/attachment-0001.html>
The alternative I had in mind would be to rewrite the commits on the branch so that all the files are under an mlir/ subdirectory, and then do a normal merge from that. On Fri, Nov 15, 2019 at 12:01 PM Mehdi AMINI <joker.eph at gmail.com> wrote:> > > 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: 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. >>> >> >> Sounds right. >> >> >>> Our top option for the integration is to perform a git subtree merge to >>> bring the MLIR history into the monorepo, here is a prototype: >>> https://github.com/joker-eph/llvm-project-with-mlir >>> >> >> I'll note that this would be the very-first merge commit on master. I'm >> not opposed to this, but others may be. (To allow this, we'd temporarily >> reconfigure github to allow pushing merge-commits, for this one commit, and >> then disable it again.) >> >> However, another issue is that subtree merges have really weird artifacts >> when trying to look through history, with e.g. git log <filename>. I think >> I'd really prefer to avoid utilizing a subtree-merge for this. >> > > Right: `git blame` work well though. The alternative would be to have a > commit to move the files under a “mlir” directory and then do a normal > merge? > I am interested to hear about other advices here :) > > Thanks, > > Mehdi > >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/89ca2c74/attachment-0001.html>
On Fri, Nov 15, 2019 at 9:16 AM James Y Knight <jyknight at google.com> wrote:> The alternative I had in mind would be to rewrite the commits on the > branch so that all the files are under an mlir/ subdirectory, and then do a > normal merge from that. >OK, this is done now: the repo reflects this.> On Fri, Nov 15, 2019 at 12:01 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> >> >> 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: 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. >>>> >>> >>> Sounds right. >>> >>> >>>> Our top option for the integration is to perform a git subtree merge to >>>> bring the MLIR history into the monorepo, here is a prototype: >>>> https://github.com/joker-eph/llvm-project-with-mlir >>>> >>> >>> I'll note that this would be the very-first merge commit on master. I'm >>> not opposed to this, but others may be. (To allow this, we'd temporarily >>> reconfigure github to allow pushing merge-commits, for this one commit, and >>> then disable it again.) >>> >>> However, another issue is that subtree merges have really weird >>> artifacts when trying to look through history, with e.g. git log >>> <filename>. I think I'd really prefer to avoid utilizing a subtree-merge >>> for this. >>> >> >> Right: `git blame` work well though. The alternative would be to have a >> commit to move the files under a “mlir” directory and then do a normal >> merge? >> I am interested to hear about other advices here :) >> >> Thanks, >> >> Mehdi >> >>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/fa0ed4a9/attachment-0001.html>
James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes:> The alternative I had in mind would be to rewrite the commits on the branch > so that all the files are under an mlir/ subdirectory, and then do a normal > merge from that.I just sent a message about import-downstream-repo.py, shown here: https://github.com/jyknight/llvm-git-migration/pull/6/commits The default mode of operation does exactly what James says here. It rewrites the commits so all blobs are under a specific subdirectory. Then you can do a merge from the rewritten MLIR HEAD. With the --import-list option you can tell the tool to preserve blobs from other subprojects alongside the MLIR blobs. I did not test that functionality much, though. With default operation, a checkout of an early MLIR commit would should only an "mlir" directory in the working directory. With --import-list you'd see all of the other subproject directories, though the contents of those other directories wouldn't change as you walked back through early MLIR history. -David