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

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 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.
Again, we need to make the tradeoffs clear.

I'm not saying the zippered approach is bad, just that it's not quite
the panacea it may seem to be.

                        -David

Le ven. 2 nov. 2018 à 07:08, David Greene via llvm-dev <
llvm-dev at lists.llvm.org> a écrit :
> 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 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.

-- 
Mehdi


> Again, we need to make the tradeoffs clear.
>
> I'm not saying the zippered approach is bad, just that it's not
quite
> the panacea it may seem to be.
>
>                         -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181102/8d649a72/attachment.html>

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