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:
https://github.com/zaquestion/lab Unfortunately it's written in Go. But I guess that's an improvement over PHP :) Cheers Simon On Sat, 3 Nov 2018 at 16:35, Ben Gamari <b...@well-typed.com> wrote: > Simon Marlow <marlo...@gmail.com> writes: > > > On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel <hvrie...@gmail.com> > > wrote: > > > >> On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote: > >> > >> > 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. > >> [..] > >> > >> 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... > >> > > > > Sorry I wasn't very clear. We would *only* squash if the author had been > > using the workflow where they add commits to revise the MR. If the author > > wants to use the stacked-diff-like workflow where they keep a groomed set > > of commits in the MR, then we would rebase and fast-forward the MR. > > > > My concern here is that we have two different workflows. People used to > > GitHub would want to use one, and people used to Phabricator would want > to > > use the other. We have to check which workflow people are using so that > we > > can decide whether to squash on merge or not. > > > Ahh, yes, I see. > > > Ben said: > > > >> This shouldn't be a problem. One can easily configure a project such > > that users are *only* allowed to fast-forward/rebase, disallowing the > > creation of merge commits. > > > > but that doesn't fully address the problem, because the series of commits > > that would get rebased onto master would include all the commits added to > > the MR to update it during the review process. Actually what we wanted to > > do in this case was squash, not rebase+fast-forward. > > > Indeed, this is a problem that we already have in the case of GitHub > pull requests. In most of these cases I end up squashing the branch > myself when I merge (in practice this contributes very little overhead; > I need to merge GitHub PR's myself anyways as we cannot use GitHub's > merge button since github.com:ghc/ghc is merely a mirror of > git.haskell.org:ghc). > > Of course, if we start taking *all* of our patches via MRs then I agree > that this may become a bit more tiresome. > > > If there was a nice way to guide people into using the Phabricator-style > > workflow, I think that would help a lot. > > > I think this is primarily a social problem and consequently it is > probably best handled by a combination of documentation (both in the > contributor documentation and the MR template text) and code review. > > One of the things I would like to do in the near future is consolidate > (and, in some cases, rewrite) our contributor documentation. The survey > indicated that there is plenty of room for improvement here. In this > past we have discussed improving in this area but lacked the bandwidth > to give the task the attention it deserves. I think now we are in better > shape to resource it sufficiently. > > Cheers, > > - Ben > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
