[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