[llvm-dev] [cfe-dev] Phabricator -> GitHub PRs?

[Emilio Cobos Álvarez via llvm-dev]

On 1/15/20 6:50 PM, David Greene wrote:
> "Doerfert, Johannes via llvm-dev" <llvm-dev at lists.llvm.org> writes:
> 
>>> Nowadays we have tools to manage the stacks for us [1][2], and that as a
>>> plus don't require arc/php to be installed on your system.
>>>
>>> I don't do much LLVM / clang stuff, but submitting stuff with [1] just works
>>> (with `moz-phab HEAD~N --no-bug`), and it should submit your last N commits
>>> separately automatically, without having to submit them one-by one and
>>> linking them via the web interface / annotate stuff in the commit message.
>>>
>>> Sorry if this is just noise, though maybe it helps.
>>
>> This looks pretty cool, thanks! I'll for sure give it a try!
> 
> Agreed, this is interesting as is git-phab.
> 
> I would like to take a step back and talk about existing use-cases in
> Phab.  People have talked a lot about linking revisions, patch series,
> parent/child relationships and so on and I have to confess I am
> struggling to understand the use-cases for these things.  Most of what I
> do upstream is simple enough to accomplish with individual patch
> submissions and reviews.  In some cases I have posted "mega-patches" for
> context purposes but I'll admit that isn't a very good workflow as
> things quickly get out of date.
> 
> I would like to understand better how people use Phab's advanced
> features and why.  For example, what drives the need for patch series
> and dependence relationships?  Some walk-through examples would be very
> helpful.

At least at Mozilla, it's good practice to split a given patch in
logical, reviewable pieces that are associated to the same bug, and that
the same or different people may need to review.

That generally makes the patches get reviewed much sooner. During
review, some of the initial parts may be good to land, while some others
may need changes.

[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.

The use cases are similar to the "I have one PR with multiple commits"
in GitHub, but with the advantage of being able to review them
individually, and thus they can land upstream sooner.

 -- Emilio