[llvm-dev] Flang landing in the monorepo - next Monday!
Mehdi AMINI via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 9 08:11:43 PST 2020
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  and .
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:
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
>  where he collects a list of concerns like this.
>  https://github.com/flang-compiler/f18/pull/854#issuecomment-572578180
>  http://lists.llvm.org/pipermail/llvm-dev/2020-January/138103.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev