<div dir="ltr"><div dir="ltr"><div>For those of us that like to upload code for review without having to go to a website and click buttons, it looks like there's this CLI tool for GitLab:<br></div><div><br></div><div> <a href="https://github.com/zaquestion/lab">https://github.com/zaquestion/lab</a></div><div><br></div><div>Unfortunately it's written in Go. But I guess that's an improvement over PHP :)</div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, 3 Nov 2018 at 16:35, Ben Gamari <<a href="mailto:ben@well-typed.com">ben@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> writes:<br>
<br>
> On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>><br>
> wrote:<br>
><br>
>> On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote:<br>
>><br>
>> > I suppose we can do a squash-merge when committing to keep the history<br>
>> > clean, but then contributors have a choice - either do GitHub-style<br>
>> > where you add commits to a PR to update it and we squash on merge, OR<br>
>> > Phabricator-style where you keep the same set of commits and rebase<br>
>> > the stack to update it.<br>
>> [..]<br>
>><br>
>> Well, if MRs are to be squashed on merge anyway, I'm definitely not<br>
>> going to waste my time carefully grooming a stack of atomic individually<br>
>> validating commits via git-rebase-interactive...<br>
>><br>
><br>
> Sorry I wasn't very clear. We would *only* squash if the author had been<br>
> using the workflow where they add commits to revise the MR. If the author<br>
> wants to use the stacked-diff-like workflow where they keep a groomed set<br>
> of commits in the MR, then we would rebase and fast-forward the MR.<br>
><br>
> My concern here is that we have two different workflows. People used to<br>
> GitHub would want to use one, and people used to Phabricator would want to<br>
> use the other. We have to check which workflow people are using so that we<br>
> can decide whether to squash on merge or not.<br>
><br>
Ahh, yes, I see.<br>
<br>
> Ben said:<br>
><br>
>> This shouldn't be a problem. One can easily configure a project such<br>
> that users are *only* allowed to fast-forward/rebase, disallowing the<br>
> creation of merge commits.<br>
><br>
> but that doesn't fully address the problem, because the series of commits<br>
> that would get rebased onto master would include all the commits added to<br>
> the MR to update it during the review process. Actually what we wanted to<br>
> do in this case was squash, not rebase+fast-forward.<br>
><br>
Indeed, this is a problem that we already have in the case of GitHub<br>
pull requests. In most of these cases I end up squashing the branch<br>
myself when I merge (in practice this contributes very little overhead;<br>
I need to merge GitHub PR's myself anyways as we cannot use GitHub's<br>
merge button since github.com:ghc/ghc is merely a mirror of<br>
git.haskell.org:ghc).<br>
<br>
Of course, if we start taking *all* of our patches via MRs then I agree<br>
that this may become a bit more tiresome.<br>
<br>
> If there was a nice way to guide people into using the Phabricator-style<br>
> workflow, I think that would help a lot.<br>
><br>
I think this is primarily a social problem and consequently it is<br>
probably best handled by a combination of documentation (both in the<br>
contributor documentation and the MR template text) and code review.<br>
<br>
One of the things I would like to do in the near future is consolidate<br>
(and, in some cases, rewrite) our contributor documentation. The survey<br>
indicated that there is plenty of room for improvement here. In this<br>
past we have discussed improving in this area but lacked the bandwidth<br>
to give the task the attention it deserves. I think now we are in better<br>
shape to resource it sufficiently.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
</blockquote></div>