<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Le lun. 5 nov. 2018 à 07:43, David Greene <<a href="mailto:dag@cray.com">dag@cray.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> writes:<br>
<br>
>     > If you want a monorepo view for all of your branches' histories<br>
>     > too it's more involved, but I'm not sure anyone really needs<br>
>     > that. In any case, even if someone does want that the nature of<br>
>     > the zipper approach means it could be done later<br>
>     > non-destructively.<br>
>     <br>
>     That's true, but then they would suffer the same duplication of<br>
>     history that motivated you to create the zippered repository in<br>
>     the first place.<br>
><br>
> It isn't clear to me why it would suffer from the same duplication of<br>
> history?<br>
> The duplication of history is only due to the *rewrite* of the git<br>
> hash between the individual repo and the monorepo.<br>
> If we were starting with a subtree merge and later add a "zipped"<br>
> history, we would only add the merges commit without rewriting<br>
> anything I think.<br>
<br>
I'm not sure how this after-the-fact merge would work.  How was the<br>
zippered monorepo history created?  Do a subtree merge of each<br>
subproject and then...?<br>
<br>
I was imagining someone taking their existing subproject repository tree<br>
and simply pushing their local branches to a clone of the zippered<br>
monorepo (ZMR).  So their commits would exist as branches off the ZMR's<br>
subproject histories.  To then get them merged into a "proper" monorepo<br>
history would require...<something>...to merge a subproject commit with<br>
an appropriate zippered commit to create a zippered local branch.<br>
That's effectively two commits for each local downstream subproject<br>
commit.</blockquote><div><br></div><div>Yes, but that's the case for the zipper repo anyway: one merge per commit. The point is that the second commit is just a trivial merge, it wouldn't show up in a file `git log` for example.</div><div>In the linear rewritten monorepo, adding the history taken from the existing git mirror would lead to duplicated commits, as in *identical* commit / commit with the same diff but different git hashes. I'd expect git log to show us the two commits in the git log of a single file.</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div>