On Wed, Jul 1, 2020 at 4:19 PM James Y Knight <jyknight at google.com> wrote: > 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 *should* 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. > > Unless someone can confirm that this *won't* happen, it's probably *not* a > good idea to push 30,000 "new" old commits into any branch in the repo. > Well, I can now confirm that this in fact does still happen. The creation of https://github.com/llvm/llvm-project/pull/232 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. But...now it's been done. So I guess that's that! The apple branch is in github.com/llvm/llvm-project (in branch refs/pull/232/head; you can checkout via `git fetch origin refs/pull/232/head && git checkout FETCH_HEAD`). 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 > github.com/apple/llvm-project, commit hash > a1fde6dadf210c937c88509ab775610213e2cfc5, and all prior commits it depends > on, under the Apache2 license with LLVM project exceptions, as listed in > https://github.com/apple/llvm-project/blob/a1fde6dadf210c937c88509ab775610213e2cfc5/LICENSE.txt". > That seems like it'd be sufficient -- and even more explicit as a statement > of intent than creating a branch! (But, of course, IANAL). > > Or -- how about both sending such a message *and* 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? > > On Wed, Jul 1, 2020 at 1:19 PM Philip Reames via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> On 6/30/20 2:07 PM, Chris Lattner via llvm-dev wrote: >> >> >> >> On Jun 30, 2020, at 2:02 PM, Duncan Exon Smith <dexonsmith at apple.com> >> wrote: >> >> >> >> On 2020-Jun-30, at 13:28, Chris Lattner via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> On Jun 29, 2020, at 10:15 PM, Chandler Carruth via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> 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. >> >> >> 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? >> >> >> 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. >> >> 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. >> >> >> Ok, Iâm not very concerned either way, it was just a thought. Iâm very >> happy to see this upstreaming work happen, thanks! >> >> -Chris >> >> 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. >> >> 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? >> >> Philip >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200714/226d0f4c/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4