<div dir="ltr"><div dir="ltr"><div>On Wed, Jul 1, 2020 at 4:19 PM James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The consequences of pushing a new branch name and then deleting it later should be low. And if we really wanted to exclude it from the default pull set, it can be placed in, "refs/staging/apple" instead of "refs/heads/staging/apple". Nothing outside refs/heads/ and refs/tags/ gets pulled by default. This <i>should</i> be the obvious answer. However, we've had cases in the past that when people have accidentally created a branch or opened a pull request (which creates a new branch in "refs/pull/NNN"), which triggered phabricator to start sending a bunch of effectively-spam emails. I believe that may still be a problem.<div><br></div><div>Unless someone can confirm that this <i>won't</i> happen, it's probably <i>not</i> a good idea to push 30,000 "new" old commits into any branch in the repo.</div></div></blockquote><div><br></div><div>Well, I can now confirm that this in fact does still happen. The creation of <a href="https://github.com/llvm/llvm-project/pull/232" target="_blank">https://github.com/llvm/llvm-project/pull/232</a> has triggered phabricator to send out emails notifying me of my commits that were in there, as if they were actually committed to a real branch. I assume the same occurred for others. This is really unfortunate behavior, and I do hope we can figure out how to configure phabricator to stop doing this.</div><div><br></div><div>But...now it's been done. So I guess that's that! The apple branch is in <a href="http://github.com/llvm/llvm-project">github.com/llvm/llvm-project</a> (in branch refs/pull/232/head; you can checkout via `git fetch origin refs/pull/232/head && git checkout FETCH_HEAD`).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'd also concur with the other comments that it really feels quite silly to do have to do anything technical here at all, versus posting an email to llvm-dev along the lines of "Apple is contributing the code added in <a href="http://github.com/apple/llvm-project" target="_blank">github.com/apple/llvm-project</a>, commit hash a1fde6dadf210c937c88509ab775610213e2cfc5, and all prior commits it depends on, under the Apache2 license with LLVM project exceptions, as listed in <a href="https://github.com/apple/llvm-project/blob/a1fde6dadf210c937c88509ab775610213e2cfc5/LICENSE.txt" target="_blank">https://github.com/apple/llvm-project/blob/a1fde6dadf210c937c88509ab775610213e2cfc5/LICENSE.txt</a>". That seems like it'd be sufficient -- and even more explicit as a statement of intent than creating a branch! (But, of course, IANAL).</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Or -- how about both sending such a message <i>and</i> creating a phab review for `git diff origin/master...swift/apple/master` (three dots diff gets the diff only from the last merge-point). Maybe that covers all the bases sufficiently?<br></div><div><div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 1, 2020 at 1:19 PM Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 6/30/20 2:07 PM, Chris Lattner via
llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<br>
<div><br>
<blockquote type="cite">
<div>On Jun 30, 2020, at 2:02 PM, Duncan Exon Smith
<<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>> wrote:</div>
<br>
<div>
<div><br>
<div><br>
<blockquote type="cite">
<div>On 2020-Jun-30, at 13:28, Chris Lattner
via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<div>
<div><br>
<div>
<blockquote type="cite">
<div>On Jun 29, 2020, at 10:15 PM,
Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<div>
<div>
<blockquote type="cite">
<div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">IMO, a pull
request isn't as clear given that they
haven't been used for contributions before.
This is not a time to be innovative IMO. A
branch as a staging location has been used
many times over the history of the project
though and seems nicely unambiguous in that
regard.</div>
</div>
</blockquote>
</div>
<br>
<div>I don’t have a opinion on this either
way, but can git/GitHub maintain forks within the
same organization? You could have
llvm/llvm-project and
llvm/llvm-project-apple-staging or something like
that?</div>
</div>
</blockquote>
<div><br>
</div>
<div>I don't think GitHub allows you fork your
own repo so I think it would be disconnected from a
GitHub point of view. That has a few downsides,
although I'm not sure how important they are.</div>
<div><br>
</div>
<div>Regardless, if a separate repo is
preferred, then a better name from our perspective
would be "llvm-project-staging" (dropping the "-apple"
suffix). We could push a "staging/apple" branch there.</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
<div>Ok, I’m not very concerned either way, it was just a thought.
I’m very happy to see this upstreaming work happen, thanks!</div>
<div><br>
</div>
<div>-Chris</div>
</blockquote>
<p>I have a mild preference for the separate llvm-project-staging
approach, but am not opposed to an in tree branch either. The
main argument I see for the separate repo is that the bar can be
lower because the consequences for being "wrong" about the code
being fully merged quickly are lower.</p>
<p>Or another thought, maybe we should even use the incubator flow
here? Nothing says an incubator has to be long lived. If we spun
up an "incubator-staging-apple" repo, wouldn't that demonstrate
the same benefits?</p>
<p>Philip<br>
</p>
<p><br>
</p>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
</div>