similar to: Phabricator picking up downstream commits from Github forks of llvm-project?

That appears to have been pushed to refs/am/changes/bbc4c751f01bb6f649942d3cf3b504a87c9019c8_swift/master-next Does someone (perhaps someone from apple) know what that is? Was it pushed there, rather than the swift fork, by mistake? On Tue, Oct 29, 2019 at 6:12 PM Anton Korobeynikov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Someone pushed these changes to LLVM repo. See e.g.

On Wed, 30 Oct 2019, Sameer Sahasrabuddhe via llvm-dev wrote: > October 30, 2019 5:58 AM, "Alex L via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > >> Oh, this explains it! Unfortunately one of our engineers made a mistake, and pushed the ref to >> wrong remote while resolving a merge conflict on https://github.com/apple/llvm-project (pushed to >>

Hi, I'm having a problem logging into phabricator using my GitHub credentials. When I click on the "Login or Register GitHub" button on the login page, my browser displays this error message: Login Failed Authentication provider ("GitHub") encountered an error during login. The OAuth provider returned an error: redirect_uri_mismatch Is anyone else having the

Hi folks, Another thought on the topic is tooling support and tool integration: There is a hughe ecosystem around Github and very little around Phabricator. It took me 2 days to set up build jobs for the 10.x release branch [1]. There are nice build integrations for Github and it was smooth sailing. Setting up a build job for pull requests would just be a few clicks now. In contrast I've

Fangrui Song via cfe-dev <cfe-dev at lists.llvm.org> writes: > > One property of "Squash and merge" is that it will add intermediate > commits as bullet points (`* `). In many cases the merger does not spend > more time cleaning up the description so a commit may look like: > > ``` > RFC: treat small negative λ as 0 for sqrt(::Hermitian) (#35057) > >

On Wed, 16 Sep 2020 at 09:37, Anton Korobeynikov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Apparently reviewable.io requests full permissions to control the > repository and its settings. > I noticed that, too. I guess that if it wants to keep a full history of all force-rebases it may need to create sub-branches for the pull requests, as well as to approve pull

Then perhaps those opposed could suggest how to use Phabricator/Arcanist so that I don't throw my keyboard through my monitor? -bw On Tue, Jan 7, 2020 at 4:33 PM Finkel, Hal J. <hfinkel at anl.gov> wrote: > > On 1/7/20 6:17 PM, Bill Wendling wrote: > > What was the verdict? Any plans to move? I hate coding anything knowing > that I'll have to use Phabricator.

Renato Golin <rengolin at gmail.com> writes: > > Don't they give you the opportunity to amend the commit message, at least? I vaguely remember it's possible. > If you mean "amend" like in "git commit --amend", it's generally a bad idea to rewrite repository history that has already been published. If you mean "amend" the message in the Web

On 01/15, Nicolai Hähnle via cfe-dev wrote: > On Tue, Jan 14, 2020 at 11:41 AM Renato Golin <rengolin at gmail.com> wrote: > > We rarely approve some patches and not others in a series, and when we > > do, we ask people to create a new series without the approved patch, > > or split them, so that we can continue reviewing the series. > > This has simply not been

What was the verdict? Any plans to move? I hate coding anything knowing that I'll have to use Phabricator. It's like nails on a chalkboard. -bw On Tue, Jan 7, 2020 at 4:13 PM Finkel, Hal J. <hfinkel at anl.gov> wrote: > > On 1/7/20 6:03 PM, Bill Wendling via llvm-dev wrote: > > Now that we're on GitHub, can we *please* move to GitHub PRs? As much as I > hate

Now that we're on GitHub, can we *please* move to GitHub PRs? As much as I hate git, I hate Phabricator/Archanist even more. They're super clunky and makes working in git that much worse. -bw -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200107/e47b7e36/attachment.html>

On Tue, 28 Jan 2020 at 16:09, David Greene <dag at cray.com> wrote: > The question is if everything is approved and the author does a final > cleanup as alluded to above, does that final cleanup also need to go > through review? We don't enforce that now, so I see no reason to start doing it. Phab reviews, once approved, can have last-minute modifications and direct commits.

On Sun, 13 Sep 2020 at 15:51, Hubert Tong <hubert.reinterpretcast at gmail.com> wrote: > If you mean "amend" the message in the Web UI before merging, then yes, >> they let you change the message, but it's very easy to forget to do >> that. > > That's what I meant, yes. "Easy to forget" generally goes away when you repeat it enough times.

> > In Github pull requests there is always a git commit that you can just >> feed to the build server. And you can be sure of what really gets merged. >> You review, build and test exactly the change that gets merged afterwards. >> > > How would that be true? Given that upstream keep changing during the > period of review? The commit is going to have to be rebased

On Thu, Jan 23, 2020 at 11:37 AM David Greene <greened at obbligato.org> wrote: > Hubert Tong <hubert.reinterpretcast at gmail.com> writes: > > >> I read this as the refresh being an entirely new GitHub PR. Is that > >> right? Normally I would expect the same PR to be used but the rebase > >> would cause a force-push of the branch which would update

On Wed, 15 Jan 2020 at 17:47, Doerfert, Johannes <jdoerfert at anl.gov> wrote: > I'd say that helping people to improve their environment is better than > forcing others to worsen theirs. Note the difference: One side is trying to *help improve", while the other is *forcing to worsen*. This is really not helpful. --renato

On Thu, Jan 16, 2020 at 1:17 PM David Greene <greened at obbligato.org> wrote: > Hubert Tong <hubert.reinterpretcast at gmail.com> writes: > > >> I can see how having multiple patches up at once for review might speed > >> things up. But what if a very first patch in a series needs major > >> changes and that affects every single following patch? The

On Wed, Jan 15, 2020 at 2:31 PM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Emilio Cobos Álvarez <emilio at crisal.io> writes: > > > [1] or [2] are recentish examples that come to mind, but it happens > > fairly often. Of course for a bunch of simpler changes one revision is > > enough. > > I think you forgot to include links. :)

On Wed, Jan 22, 2020 at 11:24 PM David Greene <greened at obbligato.org> wrote: > Christian Kühnel via llvm-dev <llvm-dev at lists.llvm.org> writes: > > >>> In Github pull requests there is always a git commit that you can just > >>> feed to the build server. And you can be sure of what really gets > merged. > >>> You review, build and test

On Thu, 16 Jan 2020 at 19:10, David Blaikie <dblaikie at gmail.com> wrote: > Can you point to examples of that - where Phab links have been used to express non-mechanically-dependent patches? Not at the top of my head, but since that's not what we're talking about, I'll go to the next point. > Approval order isn't commit order - I'm more than happy to approve a