<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> Actually my experience is radically the opposite: Phabricator is the one<br>
> that does not allow to "just being able to use Git on its<br>
> own", you're either stuck with manually exporting .patch files and manually<br>
> add them to the UI or use a php-based CLI indeed (which is the point you<br>
> seem to be against).<br>
<br>
+1.  Phab still seems alien to me and I've been using it for over a<br>
year now.<br><br></blockquote><div><br></div><div>Agreed.  I find Phabricator incredibly clunky to use compared to the github pull request interface.  It's probably somewhat of a vicious cycle though, as my perceived overhead of having to generate patch files, upload them and then deal with Phabrictator means that I tend to focus on internal facing tasks over doing upstream work where possible, which means that I grow increasingly comfortable with pull request workflow and grow my perceived barrier with the Phabricator workflow.  I'd definitely use github PRs in preference to Phab if a choice between the two were on offer.</div><div><br></div><div>I'm a big fan of the "Rebase+Merge" option though.  I'd much rather put up a single pull request encompassing multiple related commits (e.g. an initial commit containing some necessary NFC refactoring and a second commit containing the actual functional changes) and then rebase+force push to address review comments.  I've never personally had an issue with the interface in terms of seeing what's changed since the previous review.  It will be a shame if the only option we get from the web interface is to Squash, although I'd be comfortable in the above example manually cherry-picking and pushing the NFC commit directly into master and then just pulling in the functional side from the web interface if that was all that was available. </div><div><br></div><div>-Greg</div></div></div>