<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:.5in">Can you please clarify your use of “cost” (bandwidth, disk space, extra command to type initially?),<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Developer time, barrier to entry for new contributors. Getting the sparse-checkout business right looks like it is actually non-trivial and not recommended
for the git novice. *Changing* the sparse-checkout configuration later appears to be fraught with peril (easy to get wrong).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">The claim is to keep the existing history (I.e. not hash changes) that is currently at <a href="http://llvm.org/git/llvm.git">http://llvm.org/git/llvm.git</a> and continue to accumulate there any new commit that
would touch the llvm subdirectory of the unified repo.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">This would be a read-only view of course, but just like it is now.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hmmm so there's still a per-old-project view? Missed that aspect, sorry… it would let us preserve our processes in terms of integrating the flow from upstream,
although being able to get a correctly linearized flow of commits from the unified repo would be preferable and we would *want* to change over. Still not clear how to make that work with a sparse checkout.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> mehdi.amini@apple.com [mailto:mehdi.amini@apple.com]
<br>
<b>Sent:</b> Thursday, July 21, 2016 4:52 PM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> Renato Golin; Justin Lebar; llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] One or many git repositories?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jul 21, 2016, at 4:39 PM, Robinson, Paul <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<br style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">-----Original Message-----<br>
From: <a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a> [<a href="mailto:mehdi.amini@apple.com">mailto:mehdi.amini@apple.com</a>]<br>
Sent: Thursday, July 21, 2016 3:16 PM<br>
To: Robinson, Paul<br>
Cc: Renato Golin; Justin Lebar; <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
Subject: Re: [llvm-dev] [RFC] One or many git repositories?<br>
<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On Jul 21, 2016, at 2:33 PM, Robinson, Paul via llvm-dev <llvm-<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><a href="mailto:dev@lists.llvm.org">dev@lists.llvm.org</a>> wrote:<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On 21 July 2016 at 18:12, Justin Lebar <<a href="mailto:jlebar@google.com">jlebar@google.com</a>> wrote:<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">llvm, clang, clang-tools-extra, lld, polly, lldb, llgo, compiler-rt,<br>
openmp, and parallel-libs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
I really, *really* would like to see libc++ / abi / unwind. :)<br>
<br>
My reason is that, when building toolchains, the C++ ABI and unwinding<br>
are fundamental parts of the run-time library, of which RT is only<br>
part of.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
When building *your* toolchain...<br>
<br>
My toolchain uses clang but not libc++/abi/unwind, we have our own, and<br>
we don't currently include them in our tree. We do include compiler-rt.<br>
<br>
If we should change our minds later we can opt-in to anything else we<br>
want (libcxx etc, lld? lldb? who knows) but in the meantime they are<br>
unnecessary baggage for my purposes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
As a developer, you can checkout part of the repo with sparse-checkout.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
I'm not clear why imposing this cost on everybody who wants less-than-all<br>
(which I'd think would be most people) </span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Can you please clarify your use of “cost” (bandwidth, disk space, extra command to type initially?), otherwise it is hard for me to address you concerns (for instance I’m actually sensitive to the one you spelled out clearly in another
email about a commit in lld requiring a rebase in llvm).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">is superior to the submodule thing<br>
which can be maintained centrally by people who actually understand how to<span class="apple-converted-space"> </span><br>
do it.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While I see some good principled way to have a submodule umbrella repo in git, I don’t see any *without server-side hooks* that does not have any flaw*. Unfortunately this is not addressed by Renato’s proposal, and github does not allow
server-side hooks, and another git hosting service is spelled out-of-discussion for Renato’s proposal.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">* we may consider the flaws acceptable, but they need to be understood and accepted, and I don’t think it has been spelled out clearly in Renato’s proposal.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">As a downstream integrator, you can filter out the repo history as you<br>
want before merging into your repo.<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
Hmmm maybe, maybe not. It sounds like the claim is: you can do a sparse<br>
checkout of upstream, then merge it to a different branch, and get only<span class="apple-converted-space"> </span><br>
the history of the stuff that was sparsely checked out. </span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">No that’s not the claim (sparse checkout are totally unrelated to this part of my claim).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The claim is to keep the existing history (I.e. not hash changes) that is currently at <a href="http://llvm.org/git/llvm.git">http://llvm.org/git/llvm.git</a> and continue to accumulate there any new commit that would touch the llvm subdirectory
of the unified repo.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">This would be a read-only view of course, but just like it is now.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I.e. if you’re using the existing git repo, we can keep maintaining your workflow *as-is* forever. It means *no* migration would be forced on any CI/integration system (other than those relying on SVN).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(We’d need some creativity around the git-svn-id in the commit messages for the new commits though).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">— <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Mehdi<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Does this work<span class="apple-converted-space"> </span><br>
with subtree merges? Our branches are not rooted at the 'llvm' directory,<span class="apple-converted-space"> </span><br>
and I am suspicious about what the sparse checkout config would do to the<span class="apple-converted-space"> </span><br>
local branch. (I know, I should do the experiment myself, but right now<span class="apple-converted-space"> </span><br>
I'm in the middle of a release-prep circus and really shouldn't be<span class="apple-converted-space"> </span><br>
spending the time to write this email:-).)<br>
<br>
If all of this magic *does* work, then mainly it's a matter of scripting<br>
the sparse-checkout config and deploying that internally. Not free, but<br>
maybe not horrible either.<br>
--paulr<br>
<br style="font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
—<br>
Mehdi<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>