[llvm-dev] Flang landing in the monorepo - next Monday!

[Mehdi AMINI via llvm-dev]

On Thu, Jan 9, 2020 at 6:40 AM Peter Waller <Peter.Waller at arm.com> wrote:

> On 09/01/2020 03:16, Mehdi AMINI wrote:
>
> What is the latest/current proposed merge commit showing what will be
> pushed to the monorepo?
>
> Please see [0] and [1].
>

Thanks!

If you want a one-liner to obtain the master branch as it would look after
> the merge, this will create a directory called llvm-project-post-merge:
>
> git clone --single-branch -b rewritten-history-v4-llvm-project-merge
> https://github.com/peterwaller-arm/f18 llvm-project-post-merge
>
> (single-branch is necessary to avoid pulling down all the other branches I
> have in there).
>
> Can you make sure to prune/repack the repo before pushing?
>
> My understanding is that when I say "git push", object negotiation happens
> between my git client and github, and the objects github needs are sent
> there. I will only be pushing one ref (master), so I don't expect prune
> will have an effect. I don't see any way to control the repacking on the
> github side.
>
> It's not github, but gitlab's docs say they repack after all pushes:
> https://docs.gitlab.com/ee/administration/housekeeping.html
>

GitHub does not. When we migrated to the monorepo, I asked them to do a
one-time repack and the repo shrunk from 1.14GB to 650MB.
Usually with normal git operations, repacking is not necessary / useful,
but with large history rewrite it isn't necessarily the case (in the
monorepo migration, it was svn2git)

I imagine github do the same. I can't find anything in their docs to that
> effect that I can link to. I've written to github support to them to ask
> what to expect. As a quick experiment I compared the size of the packfiles
> after a clone of each:
>
> 840M    llvm-project-single-branch/.git
> 805M    f18-post-merge-single-branch/.git
>
> Hmm, the rewritten history branch, with both llvm and f18, is smaller than
> f18 alone. This suggests to me that the repositories aren't repacked at the
> same rate.
>
> Please correct me if I'm wrong. I can repack for good measure, but I don't
> think it will affect anyone other than me.
>

It seems that the way you processed the repo stayed fairly well packed
right now, so there does not seem to be a need for anything here.
When I rewrote the MLIR history the impact of repacking was non negligible
(~15% when comparing the size of the .git folder before/after repacking).


> Are the license header updated to be the LLVM license?
> The test don't seem to be lit-based testing: is this part of the TODO list?
>
> Yes on both counts. Please see Richard Barton's email, points 3 and 5 in
> [2] where he collects a list of concerns like this.
>
> [0] https://github.com/flang-compiler/f18/pull/854#issuecomment-572578180
>
> [1]
> https://github.com/peterwaller-arm/f18/commits/rewritten-history-v4-llvm-project-merge
>
> [2] http://lists.llvm.org/pipermail/llvm-dev/2020-January/138103.html
>

Looks great!

Thanks,

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200109/edbe6493/attachment.html>