similar to: MIssing llvm-commits messages

> On Dec 9, 2019, at 1:10 PM, Roman Lebedev <lebedev.ri at gmail.com> wrote: > > Yep, there seems to be an issue with commits containing non-ASCII > symbols (in Author: line?) Ah, perhaps, but I don’t seen anything obvious, at least not in the log. And the author has other commits just before and after that did generate a messages, so it seems somewhat random to me. >

On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Mehdi AMINI <joker.eph at gmail.com> writes: > > > What is the practical plan to enforce the lack of merges? When we > > looked into this GitHub would not support this unless also forcing > > every change to go through a pull request (i.e. no pre-receive hooks >

Hi, At the LLVM dev meeting, some people discussed the possibility of having pre-push and/or pre-commit hooks to avoid messing up the history when we move on to the monorepo. One of the concerns was about people starting to push merge commits and unsquashed commits upstream, resulting in a messy history. I had volunteered to write a hook that would check for the absence of merge commits in the

The current documentation talks about both the Phabricator review, and review as mail replies on -commits lists. It also talks about submitting patches to lists, with the subtext that it may be friendlier for outsiders. It is true that Phabricator has some entry threshold, larger than github, or maillists, so the attempt is not unwarranted. But from what i can tell, 99.9% patches go via

Sorry, I didn't notice this change of default last night. Thanks for fixing this! -- Mehdi On Tue, Jul 28, 2020 at 5:50 AM MyDeveloper Day via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I've made the change > > https://reviews.llvm.org/harbormaster/plan/5/ > > MyDeveloperDay <https://reviews.llvm.org/p/MyDeveloperDay/> changed the Hold > Drafts

Hello. Some time ago, https://github.com/llvm/apple-llvm-project-staging appeared. I do not recall seeing any discussions about it (especially before the fact) here. It is a standalone repository, not a fork, therefore github wrongfully counts everyones commits twice - once in the proper repo, and once in there. That can not be worked around, as far as i understand. So, why is it there in the

On Tue, Jul 28, 2020 at 3:29 PM James Y Knight <jyknight at google.com> wrote: > > Please assume good faith -- I'm pretty sure this is simply a configuration mistake, since Mehdi just upgraded Phabricator to a new upstream revision last night. > Probably the default behavior changed in the new upstream version, and it just needs to be turned off. Yep, that's why i'm

On 10/16/2019 12:02 PM, Roman Lebedev wrote: > On Wed, Oct 16, 2019 at 9:55 PM Tom Stellard <tstellar at redhat.com> wrote: >> >> On 10/16/2019 07:31 AM, Roman Lebedev wrote: >>> +1, please. >>> >>> Also, putting a tag on the *first* commit in the repo, >>> and doing `git describe --match FIRST_COMMIT_TAG` will be *great*! >>>

This is configured in the "pre-merge checks" build plan, the "Hold Drafts" needs to be set to "Never" I should be able to change this in the build plan if you want but I don't want to step on anyone's toes MyDeveloperDay On Tue, Jul 28, 2020 at 1:35 PM MyDeveloper Day <mydeveloperday at gmail.com> wrote: > See the "Draft Mode" changes,

On 03/17/2020 06:39 AM, Roman Lebedev wrote: > On Tue, Mar 17, 2020 at 4:35 PM Tom Stellard <tstellar at redhat.com> wrote: >> >> On 03/16/2020 11:09 PM, Roman Lebedev wrote: >>> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev >>> <cfe-dev at lists.llvm.org> wrote: >>>> >>>> On 03/16/2020 10:13 AM, Florian Hahn wrote:

On Mon, Jul 6, 2020 at 5:21 PM Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > There's an email thread at this point :) You mean http://lists.llvm.org/pipermail/llvm-dev/2020-July/142951.html ? I wasn't sure that was directly related - since that thread seems to be asking for permission/buy-in to /add/ a branch, it doesn't (based on my reading at

On Mon, Oct 7, 2019 at 11:32 AM Roman Lebedev <lebedev.ri at gmail.com> wrote: > > Bump. Any further thoughts here? > > To recap - i don't really see how this can be a demandedbits problem - we do > demand all those bits, we just know they must be zero. > (i would love to be proven wrong though!) > > Roman. > > On Tue, Oct 1, 2019 at 11:17 PM Roman Lebedev

Since the update, new revisions aren't posted immediately, but first appear as drafts. There's also this message: "This draft revision will be sent for review once this build passes: Build 82647: pre-merge checks." (https://reviews.llvm.org/D84742) As many have seen, pre-merge checks are flaky and just generally unusable, and this case was no exception, the build failed and the

On Thu, Jun 25, 2020 at 9:59 AM Roman Lebedev <lebedev.ri at gmail.com> wrote: > On Thu, Jun 25, 2020 at 7:48 PM Arthur Eubanks via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > After talking with some NPM people, I believe the ultimate goal after > NPM is enabled by default is to only support `-passes=`, and remove support > for `-foo-pass`. > Hm,

Please can we shut down one of the two systems for new bugs ASAP? We've already had an instance of someone filing the same bug using both systems, with two different fixes being committed by two different people at the same time... On Tue, 17 Mar 2020 at 06:49, Robinson, Paul via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > > -----Original Message----- > > From:

Hello, I sometime forget to set the "Repository" when uploading a patch on Phabricator, and that prevents from adding llvm-commits as a subscriber. [cid:image001.png at 01D61A45.E388B060] Would it make sense to set 'LLVM Github Monorepo' as a default? Or subscribe 'llvm-commits' automatically when creating a patch? Thanks! Alex. -------------- next part --------------

Hi Roman, Thanks for your good idea. I think it can solve the abs issue very well. I can continue with my work now^-^. But if it is not abs and there is no select, %res = OP i32 %b, %a %sub = sub i32 0, %b %res2 = OP i32 %sub, %a theoretically, we can still do the following transform for the above pattern: %res2 = OP i32 %sub, %a ==> %res2 = sub i32 0, %res Not sure whether we can do it

On Tue, Aug 20, 2019 at 9:25 PM Michael Spencer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Aug 19, 2019 at 12:38 PM via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi everyone. My name is DeForest Richards. I’m the technical writer who was selected to work on the LLVM project as part of the Google Season of Docs program. I’ll be helping to

Hi. As per[1], gcc-4.8 is the oldest supported *major* gcc version. But what about minor/patch versions? When https://reviews.llvm.org/D43779 was initially committed, a few[2][3] buildbots failed. As i have now looked into the issue: * but it is *REPRODUCIBLE* with gcc-4.8.4 and gcc-4.9.2 from debian oldstable (Jessie). * it is *NOT* reproducible with gcc-4.8.5 and gcc-4.9.3 from ubuntu 16.04,

On Mon, Jul 6, 2020 at 5:29 PM Eric Christopher <echristo at gmail.com> wrote: > > Yep. That thread. It got there eventually around this branch as well. It's a... long thread at this point. *nod* I think I've read it all - and don't see mention of this subproject/fork/thingy. (& that entire thread occurred after (June 29th) this email from Roman (June 21st) - and was