[llvm-dev] Phabricator Creator Pulling the Plug

[Mehdi AMINI via cfe-commits]

On Thu, Sep 30, 2021 at 8:05 PM Hubert Tong
<hubert.reinterpretcast at gmail.com> wrote:
>
> On Thu, Sep 30, 2021 at 6:56 PM Mehdi AMINI via cfe-commits <cfe-commits at lists.llvm.org> wrote:
>>
>> We talked about this with the IWG (Infrastructure Working Group) just
>> last week coincidentally.
>> Two major blocking tracks that were identified at the roundtable
>> during the LLVM Dev Meeting exactly 2 years ago are still an issue
>> today:
>>
>> 1) Replacement for Herald rules. This is what allows us to subscribe
>> and track new revisions or commits based on paths in the repo or other
>> criteria. We could build a replacement based on GitHub action or any
>> other kind of service, but this is a bit tricky (how do you store
>> emails privately? etc.). I have looked around online but I didn't find
>> another OSS project (or external company) providing a similar service
>> for GitHub unfortunately, does anyone know of any?
>>
>> 2) Support for stacked commits. I can see how to structure this
>> somehow assuming we would push pull-request branches in the main repo
>> (with one new commit per branch and cascading the pull-requests from
>> one branch to the other), otherwise this will be a major regression
>> compared to the current workflow.
>>
>> What remains unknown to me is the current state of GitHub management
>> of comments across `git commit --amend` and force push to update a
>> branch.
>
>
> Force pushing to a PR branch does make it harder for reviewers to see how review comments were addressed or what was done since they last looked at the PR. Are your use cases addressed if the workflow consists of pushing additional commits to address comments or pushing a merge commit to refresh the PR branch? When the PR is approved, the "squash and merge" option can be used to commit the patch as a single commit.

This isn't compatible with stacked commits / stacked PR unfortunately.
Also while merging main back into a branch of commits is "OK",
rebasing multiple commits is much less friendly (the same conflict may
have to be fixed over and over in each commit).

> I find the code review experience in GitHub to be a productivity drain compared to Phabricator.
>
> Older inline comments are much harder to find in GitHub.
> Much more clicking needed in GitHub to actually load everything (blocks of comments folded away, comments collapsed not because you want them collapsed but because someone else or maybe just GitHub thought it should be collapsed, source files not loaded).
> GitHub does not allow inline comments further away than a few lines from a change.

Thanks! I have the same feeling, but I didn't have anything specific
to point to and figured that this is in the scope of "I'll get used to
it", but you mention some good points here.

Best,

-- 
Mehdi