[llvm-dev] RFC: Dealing with out of tree changes and the LLVM git monorepo

David Greene via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 5 07:43:18 PST 2018


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.
>     
>     That's true, but then they would suffer the same duplication of
>     history that motivated you to create the zippered repository in
>     the first place.
>
> It isn't clear to me why it would suffer from the same duplication of
> history?
> The duplication of history is only due to the *rewrite* of the git
> hash between the individual repo and the monorepo.
> If we were starting with a subtree merge and later add a "zipped"
> history, we would only add the merges commit without rewriting
> anything I think.

I'm not sure how this after-the-fact merge would work.  How was the
zippered monorepo history created?  Do a subtree merge of each
subproject and then...?

I was imagining someone taking their existing subproject repository tree
and simply pushing their local branches to a clone of the zippered
monorepo (ZMR).  So their commits would exist as branches off the ZMR's
subproject histories.  To then get them merged into a "proper" monorepo
history would require...<something>...to merge a subproject commit with
an appropriate zippered commit to create a zippered local branch.
That's effectively two commits for each local downstream subproject
commit.

                          -David


More information about the llvm-dev mailing list