Gitlab workflow

Sat Jul 6 17:05:46 UTC 2019

I can't help but notice that there are a lot of issues caused by 
adhering to a rebase-only workflow. I understand that lots of projects 
use this workflow, but I still don't understand its popularity. Git is 
just not designed to be used this way (although I admit that git is 
flexible enough to make that statement contentious).

For instance, this current issue is due to how git tracks revisions. Git 
doesn't care about Merge Requests or Issue Numbers. It just knows the 
cryptographic hashes of the worktree's contents including the set of 
commits leading up to the current commit. If you change commits by 
rebasing, git just sees brand-new commits.

GitHub and GitLab seem to be making things worse by relying on git's 
design while layering features on top that are only sort-of compatible. 
Brand-new commits created by a rebase are no longer tied to the original 
Merge Request, since it is reliant on the very hashes that got 
obliviated by the rebase. But it's not just GitLab that gets stymied: A 
bunch of handy git commands like `git branch --contains` end up being 
useless as well. I will resist the urge to stand up even taller on my 
soapbox and list all the other convenient features of git that get 
broken by rebasing, so suffice to say that the downsides to Plain Old 
Merges that do exist seem nonetheless trivial in comparison.

Rather than argue against GHC's current practices, however, I would like 
to understand them better. What issues led to a rebase-only workflow? 
Which expert opinions were considered? What happy stories can people 
relate? We recently switched away from a rebase-only workflow at 
$workplace, and it's already made life so much nicer for us -- so I'm 
curious what unforeseen pain we might be in for. :)

-Bryan

On 7/5/19 3:14 PM, Matthew Pickering wrote:
> The target branch is already correct. The way to get the merge status
> is to first rebase the branch before pushing the merge commit.
> Unfortunately the rebase API is very slow and buggy so we had to stop
> using it.
>
>
> On Fri, Jul 5, 2019 at 1:05 PM Elliot Cameron <eacameron at gmail.com> wrote:
>> Could Marge change the target branch of an MR before merging it? Perhaps this would convince GitLab to show the right info.
>>
>> On Fri, Jul 5, 2019, 6:18 AM Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> wrote:
>>> |  You believe the one which marge posts telling you that the patch is
>>> |  merged, the commit it links to is on master so you can clearly see the
>>> |  patch has been committed.
>>>
>>> OK.  The earlier one, also from Marge, not the Discussion stream but rather in the panel at the top, says
>>>
>>>      Closed by Marge Bot 8 hours ago
>>>      The changes were not merged into master
>>>
>>> So that is an outright lie?   Yes it is closed, but contrary to the statement it _has_ been merged.
>>>
>>> It's unfortunate that this misleading display is right at top, in the summary material, while the truth (that it has been merged) is buried in the Discussion stream.
>>>
>>> Alas.  But thank you for clarifying.
>>>
>>> Is this something we can raise with the Gitlab folk?  It seems so egregiously wrong.
>>>
>>> Simon
>>>
>>>
>>> |  -----Original Message-----
>>> |  From: Matthew Pickering <matthewtpickering at gmail.com>
>>> |  Sent: 05 July 2019 10:55
>>> |  To: Simon Peyton Jones <simonpj at microsoft.com>
>>> |  Cc: ghc-devs <ghc-devs at haskell.org>
>>> |  Subject: Re: Gitlab workflow
>>> |
>>> |  It's not possible to make the MR status merged and also have a reliable
>>> |  merge bot. We used to try to make the status merged but it caused too
>>> |  much instability.
>>> |
>>> |  Merge trains might eventually work but the current iteration is not
>>> |  suitable as it doesn't work with forks.
>>> |
>>> |  You believe the one which marge posts telling you that the patch is
>>> |  merged, the commit it links to is on master so you can clearly see the
>>> |  patch has been committed.
>>> |
>>> |  Matt
>>> |
>>> |  On Fri, Jul 5, 2019 at 10:43 AM Simon Peyton Jones
>>> |  <simonpj at microsoft.com> wrote:
>>> |  >
>>> |  > |  No it is not possible due to the use of Marge to merge patches.
>>> |  > | Gitlab
>>> |  >
>>> |  > By "it" is not possible, you mean that it's not possible to make the MR
>>> |  status into "Merged". Worse, I think you are saying that some MRs will
>>> |  say "Merged" and some will say "Closed" in some random way depending on
>>> |  Marge batching.  Sigh.
>>> |  >
>>> |  > Maybe this will get better with Gitlab's new merge-train feature.
>>> |  >
>>> |  > Meanwhile, my original message also asked why the MR shows two
>>> |  contradictory messages about whether the MR has landed.  Is that also un-
>>> |  fixable?   And if so how do I figure out which one to believe?
>>> |  >
>>> |  > Thanks
>>> |  >
>>> |  > Simon
>>> |  >
>>> |  >
>>> |  >
>>> |  > |  -----Original Message-----
>>> |  > |  From: Matthew Pickering <matthewtpickering at gmail.com>
>>> |  > |  Sent: 05 July 2019 10:39
>>> |  > |  To: Simon Peyton Jones <simonpj at microsoft.com>
>>> |  > |  Cc: ghc-devs <ghc-devs at haskell.org>
>>> |  > |  Subject: Re: Gitlab workflow
>>> |  > |
>>> |  > |  Hi Simon,
>>> |  > |
>>> |  > |  No it is not possible due to the use of Marge to merge patches.
>>> |  > | Gitlab  automatically chooses the merged status as follows:
>>> |  > |
>>> |  > |  Consider two MRs both which target HEAD.
>>> |  > |
>>> |  > |  MR 1: HEAD <- A
>>> |  > |  MR 2: HEAD <- B
>>> |  > |
>>> |  > |  Marge creates a batch which contains both MR 1 and MR 2. Once the
>>> |  > | batch  succeeds, firstly MR 1 is merged.
>>> |  > |
>>> |  > |  HEAD <- A
>>> |  > |
>>> |  > |  MR 1 is closed with the *merged* status because A was merged
>>> |  > | directly  into HEAD and it matches the state of MR 1.
>>> |  > |
>>> |  > |  Then patch B gets merged and now master looks like:
>>> |  > |
>>> |  > |  HEAD <- A <- B
>>> |  > |
>>> |  > |  MR 2 is closed with closed status because B was merged into master
>>> |  > | after  A, not directly onto HEAD (as the original MR was).
>>> |  > |
>>> |  > |  There is no option to change this status in the gitlab API.
>>> |  > |
>>> |  > |  Cheers,
>>> |  > |
>>> |  > |  Matt
>>> |  > |
>>> |  > |  On Fri, Jul 5, 2019 at 8:38 AM Simon Peyton Jones via ghc-devs
>>> |  > | <ghc-  devs at haskell.org> wrote:
>>> |  > |  >
>>> |  > |  > Ben
>>> |  > |  >
>>> |  > |  > Still trying to understand GitLab.  Look at MR 1352  >
>>> |  > | https://gitl  >
>>> |  > | ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F1352&data=02%7C01%
>>> |  > | 7C  >
>>> |  > | simonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988b
>>> |  > | f8  >
>>> |  > | 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&sdata=xZZiF
>>> |  > | zO  > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&reserved=0
>>> |  > |  >
>>> |  > |  > It clearly says on the first page “The changes were not merged
>>> |  > | into  master”
>>> |  > |  > But lower down (at the end) it says “Merged in 80af...”
>>> |  > |  >
>>> |  > |  > What should I believe? Merged or not merged?
>>> |  > |  >
>>> |  > |  > Also
>>> |  > |  >
>>> |  > |  > It would be really helpful if a MR status, displayed prominently
>>> |  > | at the  top, had “Merged” as a status, not just “Closed”.  If I’m
>>> |  > | trying to check  if my has landed, and I see “Closed”, that could
>>> |  > | mean that someone has  (doubtless for good reasons) closed it
>>> |  > | manually, and that it will never  land.
>>> |  > |  >
>>> |  > |  > Would that be possible?
>>> |  > |  >
>>> |  > |  > Thanks
>>> |  > |  >
>>> |  > |  > Simon
>>> |  > |  >
>>> |  > |  > _______________________________________________
>>> |  > |  > ghc-devs mailing list
>>> |  > |  > ghc-devs at haskell.org
>>> |  > |  > http://mail.
>>> |  > |  >
>>> |  > | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C
>>> |  > | 01  >
>>> |  > | %7Csimonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f9
>>> |  > | 88  >
>>> |  > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&sdata=2a
>>> |  > | Xm  > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&reserved=0
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs