Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Moritz Angermann]

I don't think Phabricator tries to be or emulate fit in any way; I think this is a misconception. The way I see it, phabricator is just a glorified diff-dump, which is supposed to work with any VCS in principle.

All that arc essentially does is, compute the diff from an offset (e.g. master) to the current HEAD and upload that to a new or existing (--update) differential. It also adds some meta information about the range, such that arc patch supposedly knows into which commit to apply the patch to. 

By default arc does not preserve history if memory serves me right but uses the summary field exclusively for the commit message.

Hence you can go wild on your local branches (use what ever development model suites your needs) and get one final squashed commit with an extensive summary.

In my experience much of the frustration with arc comes from trying to use arc as git and grafting a hit workflow onto arc.

To me, git is the organizing (branches and commits) and snapshotting solution to keep me sane and allow for experimentations without fear of loosing anything. Arc however is the tool that allows me to take my local mess and manage it as a reviewable patch I can update from my local tree if need be.

Cheers,
 Moritz


Sent from my iPhone

> On 29 Sep 2016, at 4:03 AM, Michael Sloan <mgsloan at gmail.com> wrote:
> 
>> On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari <ben at smart-cactus.org> wrote:
>> That being said, I ultimately decided it would be easier to just
>> continue carrying out this workflow by hand considering I don't post
>> large series of patches *that* often. I'm also a bit more eager to
>> squash now than I used to be, in part due to the pain of submitting
>> fine-grained patch sets. On the whole I do wish that Phabricator were
>> more Git-like.
> 
> Indeed, I do not know the details of phab / arc, but when encountering
> them, the workflow seemed unlike ordinary git workflows.  It felt like
> it is working hard to implement an atypical git workflow, and learning
> this new workflow takes work.  From the perspective of a contributor,
> it seemed strange since git's usual workflows are wildly successful
> and popular.  Granted, it is easy for people to screw those up too,
> such as by using "git pull" instead of "git pull --rebase" orso.
> 
> -Michael
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs