similar to: Phabricator -> GitHub PRs?

Displaying 20 results from an estimated 5000 matches similar to: "Phabricator -> GitHub PRs?"

2020 Mar 05
2
Allowing PRs on GitHub for some subprojects
On 2020-03-04, Louis Dionne via llvm-dev wrote: > > >> On Mar 4, 2020, at 12:13, Mehdi AMINI <joker.eph at gmail.com> wrote: >> >> >> >> On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com <mailto:ldionne at apple.com>> wrote: >> Mehdi, Chris & others, >> >> I guess I did not express the main reasons for
2020 Mar 05
2
Allowing PRs on GitHub for some subprojects
On Wed, Mar 4, 2020 at 9:42 AM Louis Dionne <ldionne at apple.com> wrote: > > > On Mar 4, 2020, at 12:13, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com> wrote: > >> Mehdi, Chris & others, >> >> I guess I did not express the main reasons for wanting to switch over
2020 Mar 04
4
Allowing PRs on GitHub for some subprojects
On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com> wrote: > Mehdi, Chris & others, > > I guess I did not express the main reasons for wanting to switch over very > well in my original message. > You original message was about “ commit attribution”, but now it is all about testing? Instead of jumping to a solution (pull-request) why not expressing the
2020 Mar 01
6
Allowing PRs on GitHub for some subprojects
On Tue, Feb 25, 2020 at 4:19 AM Christian Kühnel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Louis, > > I think this is a good idea. We should start with some local experiments > where people are willing to try it and figure out how well that works and > what does not. Why not allow this for "not significant" changes? They are > merged without review
2020 Jan 22
2
Phabricator -> GitHub PRs?
> > 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
2020 Sep 13
1
[cfe-dev] Phabricator -> GitHub PRs?
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) > >
2020 Sep 16
2
[cfe-dev] Phabricator -> GitHub PRs?
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
2020 Jan 08
5
Phabricator -> GitHub PRs?
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>
2020 Sep 13
2
[cfe-dev] Phabricator -> GitHub PRs?
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
2020 Jan 08
3
Phabricator -> GitHub PRs?
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
2020 Jan 15
2
[cfe-dev] Phabricator -> GitHub PRs?
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
2020 Sep 13
2
[cfe-dev] Phabricator -> GitHub PRs?
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.
2020 Jan 08
3
Phabricator -> GitHub PRs?
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.
2019 Dec 13
2
RFC: Using GitHub Actions for CI testing on the release/* branches
> I think my concern is that LLVM could prove to be too big and require too many resources for github's infrastructure. How many patches go into LLVM a day, and how many build and test jobs does GitHub allow users to run concurrently before being throttled? Please, no one confuse "what should be LLVM's official CIs" with "what can we do to make it easier for individuals
2020 Jan 23
2
Phabricator -> GitHub PRs?
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
2020 Jan 28
2
[cfe-dev] Phabricator -> GitHub PRs?
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.
2020 Feb 20
6
Allowing PRs on GitHub for some subprojects
Hi, I know there has been significant discussion about "moving" from Phabricator to GitHub reviews and pull requests, etc. I'm not suggesting that we do anything in terms of global LLVM policy. However, as a maintainer of libc++, I commit __a lot__ of other people's code for them. It would be a huge time saver for me if I could nicely suggest to contributors (not force them) to
2020 Jan 23
2
[cfe-dev] Phabricator -> GitHub PRs?
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
2020 Jan 15
2
[cfe-dev] Phabricator -> GitHub PRs?
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
2020 Jan 16
2
Phabricator -> GitHub PRs?
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