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
On Mon, Nov 18, 2019 at 8:34 AM David Greene <greened at obbligato.org> wrote:> 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. >I used `git-filter-repo`, but that is exactly what I've been doing actually.> > 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.Right that what I have right now in the repo, for example: https://github.com/joker-eph/llvm-project-with-mlir/tree/291a8e7ca113c4a8fc597fc0ec1a3a4e4e639f78> 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. >OK, but that seems like a "wrong" history: the state would seem quite misleading to me by mixing a recent LLVM with an old MLIR (and the code wouldn't be able to build successfully at any of these revisions). Can you clarify why would you prefer this over just a single `mlir` directory? Thanks, -- Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191118/c1563f51/attachment.html>
Mehdi AMINI <joker.eph at gmail.com> writes:>> 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. >> > > I used `git-filter-repo`, but that is exactly what I've been doing actually.Great!>> With default operation, a checkout of an early MLIR commit would should >> only an "mlir" directory in the working directory. > > > Right that what I have right now in the repo, for example: > https://github.com/joker-eph/llvm-project-with-mlir/tree/291a8e7ca113c4a8fc597fc0ec1a3a4e4e639f78Ok.>> 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. >> > > OK, but that seems like a "wrong" history: the state would seem quite > misleading to me by mixing a recent LLVM with an old MLIR (and the code > wouldn't be able to build successfully at any of these revisions). > Can you clarify why would you prefer this over just a single `mlir` > directory?I don't necessarily prefer it, I was just pointing it out as an option. I'd be perfectly happy going with what you've got now! -David