[GHC DevOps Group] The future of Phabricator

[Ben Gamari]

Herbert Valerio Riedel <hvriedel at gmail.com> writes:

> On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote:
>
>> What about the wiki? Can we migrate that off Trac too?
>
> I worry that it's a lot of work to migrate it away while preserving the
> special markup and features that Trac provides; so the resulting pages
> will require a significant amount of manual cleanup and finding ways to
> emulate the previous features; for instance, I've been using features
> like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow
> to highlight important information and footnote-like annotations in; and
> thus IMO help contribute to present the information less
> wall-of-text-ish which is harder to digest.
>
> [...]
>
>> I suppose we can do a squash-merge when committing to keep the history
>> clean, but then contributors have a choice - either do GitHub-style
>> where you add commits to a PR to update it and we squash on merge, OR
>> Phabricator-style where you keep the same set of commits and rebase
>> the stack to update it.
>
> (Minor nitpick: in GitLab there are no pull-requests (PRs) anymore;
> they're called "MRs" for "merge-request", which is probably a more
> accurate term to describe the concept than "PR" is)
>
> Well, if MRs are to be squashed on merge anyway, I'm definitely not
> going to waste my time carefully grooming a stack of atomic individually
> validating commits via git-rebase-interactive...
>
>> If you want to do dependent commits then you have to use Phabricator
>> style. Choices between workflows make things more complicated for
>> contributors, and that worries me.
>
> ...submitting a stacked set of commits as invidual overlapping MRs
> (i.e. where the first MR has only the first commit, the 2nd has the
> first two commits from the stack, and so on) -- if that's what you're
> referring to as "Phabricator-style" -- sounds like an awkward workflow
> to me.
>
Right this is not the workflow I would advocate. Rather, just submit a
single MR with your atomic changes represented as commits. In fact, this
is already what I do locally when preparing stacked Phabricator
differentials (to put another way, one commit == one differential).

GitLab has good support for reviewing commit-by-commit.

>> Does GitLab keep the history of a PR after it has been updated, like in
>> Phabricator? So we can see what happened between versions of a PR?
>
> I wonder too how this is represented in GitLab... especially when a MR
> is comprised of multiple commits, and those individual commits evolve,
> might get reordered, commits added or removed fromt he stack, or when
> the whole MR gets rebased in the process...

To be clear, GitLab saves each head commit that you push to an MR
branch. These iterations are known in the review interface as "versions".
The review interface then allows you to view differences between either

 a. any two versions
 b. any version and the target branch (e.g. master)

Unfortunately (but perhaps not unexpectedly) this scheme does not deal
well with changes due to a change in base commit (as would happen in the
case of rebasing). It appears that GitLab must just run `git diff`
between the two heads when asked to compare two versions of a MR.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181102/a239e341/attachment.sig>