<div dir="ltr">On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com">hvriedel@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>Ben said: </div><div><br></div><div>> 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.</div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">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.</span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">If there was a nice way to guide people into using the Phabricator-style workflow, I think that would help a lot.<br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">Cheers</span></div><div><span class="gmail-im">Simon</span></div><div><span class="gmail-im"><br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> If you want to do dependent commits then you have to use Phabricator<br>
> style. Choices between workflows make things more complicated for<br>
> contributors, and that worries me.<br>
<br>
...submitting a stacked set of commits as invidual overlapping MRs<br>
(i.e. where the first MR has only the first commit, the 2nd has the<br>
first two commits from the stack, and so on) -- if that's what you're<br>
referring to as "Phabricator-style" -- sounds like an awkward workflow<br>
to me.<br>
<br>
> Does GitLab keep the history of a PR after it has been updated, like in<br>
> Phabricator? So we can see what happened between versions of a PR?<br>
<br>
I wonder too how this is represented in GitLab... especially when a MR<br>
is comprised of multiple commits, and those individual commits evolve,<br>
might get reordered, commits added or removed fromt he stack, or when<br>
the whole MR gets rebased in the process...<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>