Gitlab workflow

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Gitlab workflow

GHC - devs mailing list

Ben

Still trying to understand GitLab.  Look at MR 1352 https://gitlab.haskell.org/ghc/ghc/merge_requests/1352

  • 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Matthew Pickering
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
<[hidden email]> wrote:

>
> Ben
>
> Still trying to understand GitLab.  Look at MR 1352 https://gitlab.haskell.org/ghc/ghc/merge_requests/1352
>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Gitlab workflow

GHC - devs mailing list
|  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 <[hidden email]>
|  Sent: 05 July 2019 10:39
|  To: Simon Peyton Jones <[hidden email]>
|  Cc: ghc-devs <[hidden email]>
|  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-
|  [hidden email]> wrote:
|  >
|  > Ben
|  >
|  > Still trying to understand GitLab.  Look at MR 1352
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F1352&amp;data=02%7C01%7C
|  > simonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988bf8
|  > 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=xZZiFzO
|  > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&amp;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
|  > [hidden email]
|  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
|  > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C01
|  > %7Csimonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=2aXm
|  > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&amp;reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Matthew Pickering
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
<[hidden email]> 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 <[hidden email]>
> |  Sent: 05 July 2019 10:39
> |  To: Simon Peyton Jones <[hidden email]>
> |  Cc: ghc-devs <[hidden email]>
> |  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-
> |  [hidden email]> wrote:
> |  >
> |  > Ben
> |  >
> |  > Still trying to understand GitLab.  Look at MR 1352
> |  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> |  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F1352&amp;data=02%7C01%7C
> |  > simonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988bf8
> |  > 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=xZZiFzO
> |  > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&amp;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
> |  > [hidden email]
> |  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
> |  > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C01
> |  > %7Csimonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988
> |  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=2aXm
> |  > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&amp;reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Gitlab workflow

GHC - devs mailing list
|  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 <[hidden email]>
|  Sent: 05 July 2019 10:55
|  To: Simon Peyton Jones <[hidden email]>
|  Cc: ghc-devs <[hidden email]>
|  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
|  <[hidden email]> 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 <[hidden email]>
|  > |  Sent: 05 July 2019 10:39
|  > |  To: Simon Peyton Jones <[hidden email]>
|  > |  Cc: ghc-devs <[hidden email]>
|  > |  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-  [hidden email]> wrote:
|  > |  >
|  > |  > Ben
|  > |  >
|  > |  > Still trying to understand GitLab.  Look at MR 1352  >
|  > | https://gitl  >
|  > | ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F1352&amp;data=02%7C01%
|  > | 7C  >
|  > | simonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988b
|  > | f8  >
|  > | 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=xZZiF
|  > | zO  > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&amp;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
|  > |  > [hidden email]
|  > |  > http://mail.
|  > |  >
|  > | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C
|  > | 01  >
|  > | %7Csimonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f9
|  > | 88  >
|  > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=2a
|  > | Xm  > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&amp;reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Elliot Cameron-2
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 <[hidden email]> 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 <[hidden email]>
|  Sent: 05 July 2019 10:55
|  To: Simon Peyton Jones <[hidden email]>
|  Cc: ghc-devs <[hidden email]>
|  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
|  <[hidden email]> 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 <[hidden email]>
|  > |  Sent: 05 July 2019 10:39
|  > |  To: Simon Peyton Jones <[hidden email]>
|  > |  Cc: ghc-devs <[hidden email]>
|  > |  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-  [hidden email]> wrote:
|  > |  >
|  > |  > Ben
|  > |  >
|  > |  > Still trying to understand GitLab.  Look at MR 1352  >
|  > | https://gitl  >
|  > | ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F1352&amp;data=02%7C01%
|  > | 7C  >
|  > | simonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988b
|  > | f8  >
|  > | 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=xZZiF
|  > | zO  > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&amp;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
|  > |  > [hidden email]
|  > |  > http://mail.
|  > |  >
|  > | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C
|  > | 01  >
|  > | %7Csimonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f9
|  > | 88  >
|  > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=2a
|  > | Xm  > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&amp;reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Matthew Pickering
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> |  Sent: 05 July 2019 10:55
>> |  To: Simon Peyton Jones <[hidden email]>
>> |  Cc: ghc-devs <[hidden email]>
>> |  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
>> |  <[hidden email]> 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 <[hidden email]>
>> |  > |  Sent: 05 July 2019 10:39
>> |  > |  To: Simon Peyton Jones <[hidden email]>
>> |  > |  Cc: ghc-devs <[hidden email]>
>> |  > |  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-  [hidden email]> wrote:
>> |  > |  >
>> |  > |  > Ben
>> |  > |  >
>> |  > |  > Still trying to understand GitLab.  Look at MR 1352  >
>> |  > | https://gitl  >
>> |  > | ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F1352&amp;data=02%7C01%
>> |  > | 7C  >
>> |  > | simonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988b
>> |  > | f8  >
>> |  > | 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=xZZiF
>> |  > | zO  > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&amp;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
>> |  > |  > [hidden email]
>> |  > |  > http://mail.
>> |  > |  >
>> |  > | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C
>> |  > | 01  >
>> |  > | %7Csimonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f9
>> |  > | 88  >
>> |  > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=2a
>> |  > | Xm  > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&amp;reserved=0
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Bryan Richter-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> |  Sent: 05 July 2019 10:55
>>> |  To: Simon Peyton Jones <[hidden email]>
>>> |  Cc: ghc-devs <[hidden email]>
>>> |  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
>>> |  <[hidden email]> 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 <[hidden email]>
>>> |  > |  Sent: 05 July 2019 10:39
>>> |  > |  To: Simon Peyton Jones <[hidden email]>
>>> |  > |  Cc: ghc-devs <[hidden email]>
>>> |  > |  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-  [hidden email]> wrote:
>>> |  > |  >
>>> |  > |  > Ben
>>> |  > |  >
>>> |  > |  > Still trying to understand GitLab.  Look at MR 1352  >
>>> |  > | https://gitl  >
>>> |  > | ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F1352&amp;data=02%7C01%
>>> |  > | 7C  >
>>> |  > | simonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988b
>>> |  > | f8  >
>>> |  > | 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=xZZiF
>>> |  > | zO  > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&amp;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
>>> |  > |  > [hidden email]
>>> |  > |  > http://mail.
>>> |  > |  >
>>> |  > | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C
>>> |  > | 01  >
>>> |  > | %7Csimonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f9
>>> |  > | 88  >
>>> |  > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=2a
>>> |  > | Xm  > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&amp;reserved=0
>>> _______________________________________________
>>> ghc-devs mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Brandon Allbery
For one, merge commits tend to be big, annoying, and a problem for anyone who finds themself working on something that someone else just blew away or rewrote because they weren't checking back and you can't pick only part of the merge commit unless it's itself broken into multiple commits per file or sub-change (yes ideally they all would be the latter, but then you just made big changes like refactorings impossible). The more distributed the project is, the more rebase makes a lot of sense vs. merge commits; you need a lot more central planning and organization for merge commits to work well. Which itself seems kinda anti-git.

On Sat, Jul 6, 2019 at 1:06 PM Bryan Richter <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> |  Sent: 05 July 2019 10:55
>>> |  To: Simon Peyton Jones <[hidden email]>
>>> |  Cc: ghc-devs <[hidden email]>
>>> |  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
>>> |  <[hidden email]> 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 <[hidden email]>
>>> |  > |  Sent: 05 July 2019 10:39
>>> |  > |  To: Simon Peyton Jones <[hidden email]>
>>> |  > |  Cc: ghc-devs <[hidden email]>
>>> |  > |  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-  [hidden email]> wrote:
>>> |  > |  >
>>> |  > |  > Ben
>>> |  > |  >
>>> |  > |  > Still trying to understand GitLab.  Look at MR 1352  >
>>> |  > | https://gitl  >
>>> |  > | ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F1352&amp;data=02%7C01%
>>> |  > | 7C  >
>>> |  > | simonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988b
>>> |  > | f8  >
>>> |  > | 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=xZZiF
>>> |  > | zO  > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&amp;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
>>> |  > |  > [hidden email]
>>> |  > |  > http://mail.
>>> |  > |  >
>>> |  > | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C
>>> |  > | 01  >
>>> |  > | %7Csimonpj%40microsoft.com%7Ce03ba07f29c447c1252e08d7012c9b59%7C72f9
>>> |  > | 88  >
>>> |  > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&amp;sdata=2a
>>> |  > | Xm  > n8ewTaA3S8y5eg0sa0lIed7L7BQRfm4jRTTvoO8%3D&amp;reserved=0
>>> _______________________________________________
>>> ghc-devs mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


--
brandon s allbery kf8nh

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Sven Panne-2
In reply to this post by Bryan Richter-2
Am Sa., 6. Juli 2019 um 19:06 Uhr schrieb Bryan Richter <[hidden email]>:
[...] 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. :)

I've worked for several companies of several sizes, and from my experience the rule is: The bigger the company, the more there is a tendency to use a rebase-only workflow, with big/huge projects exclusively relying on rebases, explicitly forbidding (non-fast-forward) merges. There are several good reasons for this IMHO:

   * Clarity: Even with a single release branch, merges tend to create an incomprehensible mess in the history. Things get totally unmanageable when you have to support several releases in various branches. IMHO this reason alone is enough to rule out non-fast-forward merges in bigger projects.

   * Bisecting: With merges you will have a very, very hard time bisecting your history to find a bug (or a fix). With a linear (single release) or tree-shaped (for several supported releases) history, this gets trivial and can easily be automated.

   * Hash instability: Simply relying on a hash to find out if a fix/feature is in some branch is an illusion: Sooner or later you get a merge conflict and need to modify your commit.

   * Tool integration via IDs: For the reason stated above, you will have some kind of bug/feature/issue/...-ID e.g. in your commit message, anyway. This ID is then used in your issue tracker/release management tool/..., not the hash of a commit in some branch.

Of course your mileage may vary, depending on your team and project size, the additional tools you use, how good your CI/testing/release framework is, etc.  GitLab's machinery may still be in it's infancy, but some kind of bot picking/testing/committing (even reverting, if necessary) your changes is a very common and scalable way of doing things. Or the other way round: If you don't do this, and your project gets bigger, you have an almost 100% guarantee that the code in your repository is broken in some way. :-}

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Bryan Richter-2
On 7/6/19 11:22 PM, Sven Panne wrote:
Am Sa., 6. Juli 2019 um 19:06 Uhr schrieb Bryan Richter <[hidden email]>:
[...] 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. :)

I've worked for several companies of several sizes, and from my experience the rule is: The bigger the company, the more there is a tendency to use a rebase-only workflow, with big/huge projects exclusively relying on rebases, explicitly forbidding (non-fast-forward) merges.

How does the scaling argument reconcile with the massive scope of the Linux kernel, the project for which git was created? I can find some middle ground with the more specific points you made in your email, but I have yet to understand how the scaling argument holds water when Linux trucks along with "4000 developers, 450 different companies, and 200 new developers each release"[1]. What makes Linux special in this regard? Is there some second inflection point?

-Bryan

[1]: Stated by Greg Kroah-Hartman in a few of his talks, like https://www.youtube.com/watch?v=L8OOzaqS37s or  https://www.youtube.com/watch?v=vyenmLqJQjs .


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Sven Panne-2
Am So., 7. Juli 2019 um 17:06 Uhr schrieb Bryan Richter <[hidden email]>:
How does the scaling argument reconcile with the massive scope of the Linux kernel, the project for which git was created? I can find some middle ground with the more specific points you made in your email, but I have yet to understand how the scaling argument holds water when Linux trucks along with "4000 developers, 450 different companies, and 200 new developers each release"[1]. What makes Linux special in this regard? Is there some second inflection point?

Well, somehow I saw that example coming... :-D I think the main reason why things work for Linux is IMHO the amount of highly specialized high-quality maintainers, i.e. the people who pick the patches into the (parts of) the releases they maintain, and who do it as their main (sole?) job. In addition they have a brutal review system plus an army of people continuously testing *and* they have Linus.

Now look at your usual company: You have average people there (at best), silly deadlines for silly features, no real maintainers with the power to reject/revert stuff (regardless of any deadline), your testing is far from where it should be etc. etc. Then you do everything to keep things as simple as possible, and having a repository with no merge commits *is* much easier to handle than one with merges. If you are happy with merge commits, by all means continue to use them. The "right" way of doing things depends on so many factors (project size/complexity, number/qualification of people/maintainers, release strategy/frequency, ...) that there is probably no silver bullet. The good thing is: Git doesn't prescribe you a special kind of workflow, it is more of a toolbox to build your own.

I would very much like to turn the question around: I never fully understood why some people like merge-based workflows so much. OK, you can see that e.g. commits A, B, and C together implement feature X, but to be honest: After the feature X landed, probably nobody really cares about the feature's history anymore, you normally care much more about: Which commit broke feature Y? Which commit slowed down things? Which commit introduced a space leak/race condition?

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Gitlab workflow

Ben Gamari-3
In reply to this post by GHC - devs mailing list
Simon Peyton Jones via ghc-devs <[hidden email]> writes:

> |  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.
>
Indeed this is a bit of a limitation of GitLab and is a result of the
fact that our Marge fork uses a somewhat hacky workflow for its merges
to work around other GitLab bugs.

There is indeed GitLab issue [1] requesting the ability to manually mark
merge requests as merged, but it seems unlikely that this will happen in
the near future.

Thankfully, our days of using Marge are numbered. GitLab 12.0, which
shipped two weeks ago, introduced Merge Train support. I haven't yet
upgraded our installation but will try to do so this week.

There are a few annoying limitations of merge train support surrounding
forks, but I believe we can work around these for the time being.

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/3033

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Bryan Richter-2
In reply to this post by Sven Panne-2
On 7/7/19 7:53 PM, Sven Panne wrote:> Am So., 7. Juli 2019 um 17:06
Uhr schrieb Bryan Richter <[hidden email] >:

 > > How does the scaling argument reconcile with the massive scope
 > > of the Linux kernel, the project for which git was created? I
 > > can find some middle ground with the more specific points
 > > you made in your email, but I have yet to understand how the
 > > scaling argument holds water when Linux trucks along with "4000
 > > developers, 450 different companies, and 200 new developers each
 > > release"[1]. What makes Linux special in this regard? Is there
 > > some second inflection point?
 >
 >
 > Well, somehow I saw that example coming... :-D I think the main
 > reason why things work for Linux is IMHO the amount of highly
 > specialized high-quality maintainers, i.e. the people who pick the
 > patches into the (parts of) the releases they maintain, and who do
 > it as their main (sole?) job. In addition they have a brutal review
 > system plus an army of people continuously testing *and* they have
 > Linus.

:D

I would add to your argument that they appear to use git primarily
to *keep a record of merges*. Incoming patches have no history
whatsoever; they're just individual patches. I guess that could be
considered a simpler-to-use version of the fast-forward-only strategy!
Perhaps Linux isn't such a great counterexample after all....

Once they have committed patches to some particular history, though,
they don't rebase, since that would rewrite important audit history.

 > I would very much like to turn the question around: I never fully
 > understood why some people like merge-based workflows so much. OK,
 > you can see that e.g. commits A, B, and C together implement feature
 > X, but to be honest: After the feature X landed, probably nobody
 > really cares about the feature's history anymore, you normally care
 > much more about:  Which commit broke feature Y? Which commit slowed
 > down things? Which commit introduced a space leak/race condition?

What I *don't* like is rewriting history, for all the reasons I don't
like mutable state. As you say, what you're generally interested in is
commits. When references to commits (in emails etc.) get invalidated,
it adds confusion and extra work. Seeing this happen is what led me to
wonder why people even prefer this strategy.

On top of that, many of the problems people have with merges actually
seem to be problems with bad commits, as you yourself hinted. Other
concerns seem to be based in unfamiliarity with git's features, or an
irrational desire for "pure history". (Merges *are* history!)

One final thing I like about merges is conflict resolution. Resolving
conflicts via rebase is something I get wrong 40% of the time. It's
hard. Even resolving a conflict during a merge is hard, but it's
easier. Plus, the eventual merge commit keeps a record of the
resolution! (I only learned this recently, since `git log` doesn't
show it by default.) Keeping a public record of how a conflict was
resolved seems like a huge benefit.

In the end, my main takeaway is that good commits are just as
important as good code, regardless of strategy.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Ben Gamari-2
Bryan Richter <[hidden email]> writes:

> On 7/7/19 7:53 PM, Sven Panne wrote:> Am So., 7. Juli 2019 um 17:06
> Uhr schrieb Bryan Richter <[hidden email] >:
>
>  > > How does the scaling argument reconcile with the massive scope
>  > > of the Linux kernel, the project for which git was created? I
>  > > can find some middle ground with the more specific points
>  > > you made in your email, but I have yet to understand how the
>  > > scaling argument holds water when Linux trucks along with "4000
>  > > developers, 450 different companies, and 200 new developers each
>  > > release"[1]. What makes Linux special in this regard? Is there
>  > > some second inflection point?
>  >
>  >
>  > Well, somehow I saw that example coming... :-D I think the main
>  > reason why things work for Linux is IMHO the amount of highly
>  > specialized high-quality maintainers, i.e. the people who pick the
>  > patches into the (parts of) the releases they maintain, and who do
>  > it as their main (sole?) job. In addition they have a brutal review
>  > system plus an army of people continuously testing *and* they have
>  > Linus.
>
> :D
>
> I would add to your argument that they appear to use git primarily
> to *keep a record of merges*. Incoming patches have no history
> whatsoever; they're just individual patches. I guess that could be
> considered a simpler-to-use version of the fast-forward-only strategy!
> Perhaps Linux isn't such a great counterexample after all....
>
> Once they have committed patches to some particular history, though,
> they don't rebase, since that would rewrite important audit history.
>
>  > I would very much like to turn the question around: I never fully
>  > understood why some people like merge-based workflows so much. OK,
>  > you can see that e.g. commits A, B, and C together implement feature
>  > X, but to be honest: After the feature X landed, probably nobody
>  > really cares about the feature's history anymore, you normally care
>  > much more about:  Which commit broke feature Y? Which commit slowed
>  > down things? Which commit introduced a space leak/race condition?
>
> What I *don't* like is rewriting history, for all the reasons I don't
> like mutable state. As you say, what you're generally interested in is
> commits. When references to commits (in emails etc.) get invalidated,
> it adds confusion and extra work. Seeing this happen is what led me to
> wonder why people even prefer this strategy.
>
I would reiterate this. In my experience when I'm looking back at GHC's
history I'm probably doing so for one of a few possible reasons:

 * I want to know which patch broke something
 * I want to know which patch made something slower
 * I want to know which patch added something

In all of these cases I (personally) find a linear history makes
reasoning about the progression of changes much easier. Bisection,
blame, and performance analysis tools are all much easier when you have
only one "past" to worry about.

> On top of that, many of the problems people have with merges actually
> seem to be problems with bad commits, as you yourself hinted. Other
> concerns seem to be based in unfamiliarity with git's features, or an
> irrational desire for "pure history". (Merges *are* history!)
>
> One final thing I like about merges is conflict resolution. Resolving
> conflicts via rebase is something I get wrong 40% of the time. It's
> hard. Even resolving a conflict during a merge is hard, but it's
> easier.
>
I strongly disagree here. In my experience, resolving conflicts via
rebase is much easier than doing so via merge (which is one of the
reason why I personally use a rebase workflow even outside of GHC).

The difference is that during a rebase workflow I can reason about the
changes made by each commit individually. I can look at the diff of the
original commit (which is generally small, if history was constructed
well), refer to the relevant subset of changes from the new commits I'm
rebasing on top of, and adapt my changes needing only this "local"
state.

By contrast during a merge I need to keep both the entirety of my branch
as well as every new commit that I'm merging into in my head. Not only
is this often plain infeasible (e.g. I can't imagine trying to do this
with the recent concurrent GC patches), but you end up with a result
that is incoherent since changes that were likely relevant to your
feature branch commits end up recorded in the merge commit.

> Plus, the eventual merge commit keeps a record of the
> resolution! (I only learned this recently, since `git log` doesn't
> show it by default.) Keeping a public record of how a conflict was
> resolved seems like a huge benefit.

I'm not sure I see the value in this. To me it seems like the merge
resolution is just another step in the *development* of the patch. We
generally don't preserve such steps in history. We only care about the
fully-consistent state of the patch when it is merged.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Sven Panne-2
In reply to this post by Bryan Richter-2
Am Do., 11. Juli 2019 um 14:32 Uhr schrieb Bryan Richter <[hidden email]>:
[...] When references to commits (in emails etc.) get invalidated,
it adds confusion and extra work. Seeing this happen is what led me to
wonder why people even prefer this strategy.

I think there is a misunderstanding here: You never ever force-push rebased commits to a public repo, this would indeed change commit hashes and annoy all your collaborators like hell. In a rebase-only workflow you rebase locally, pushing your then fast-forward-only merge to the public repo. You can even disable force-pushed on the receiving side, an that's what is normally done (well, not on GitHub...).
 
[...] One final thing I like about merges is conflict resolution. Resolving
conflicts via rebase is something I get wrong 40% of the time. It's
hard. Even resolving a conflict during a merge is hard, but it's
easier.

Hmmm, I don't see a difference with conflict resolution in both cases, the work involved is equivalent.
 
Plus, the eventual merge commit keeps a record of the
resolution! (I only learned this recently, since `git log` doesn't
show it by default.) Keeping a public record of how a conflict was
resolved seems like a huge benefit. [...]

To me it is quite the opposite: In a collaborative environment, I don't care even the tiniest bit about how somebody resolved the conflicts of his branch: This is a technical artifact about when the branch was made and when it is merged.

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Bardur Arantsson-2
In reply to this post by Ben Gamari-2
On 11/07/2019 17.47, Ben Gamari wrote:
[--snip--]

I'm just going to snip all of that because that was an almost perfect
summary of why rebase-always is best.

I'm *not* talking about rebasing willy-nilly, but I agree that rebasing
private branches and rebasing-with-agreement is superior in every way to
the just-merge-things approach... and you formulated it perfectly. Thank
you.

Regards,

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Gitlab workflow

Bryan Richter-2
In reply to this post by Sven Panne-2
This thread has helped my shift some of my perceptions, but,

On 7/11/19 6:49 PM, Sven Panne wrote:

 > Am Do., 11. Juli 2019 um 14:32 Uhr schrieb Bryan Richter
 > <[hidden email]>:
 >
 > > [...] When references to commits (in emails etc.) get invalidated,
 > > it adds confusion and extra work. Seeing this happen is what led
 > > me to wonder why people even prefer this strategy.
 >
 >
 > I think there is a misunderstanding here: You never ever force-push
 > rebased commits to a public repo, this would indeed change commit
 > hashes and annoy all your collaborators like hell.

This current thread started precisely because history was rewritten
and GitLab could not ascertain that a merge had happened. :)

Even if GitLab develops a feature that synchronizes these upstream
rebases with the relevant merge request, the problem will still remain
in downstream repositories. The source branch of a rebased merge
request always ends up orphaned on forks and local repositories.

I see why people might make that trade-off, however. And I see that
`git cherry` specifically considers this workflow:

     Determine whether there are commits in <head>..<upstream> that are
     equivalent to those in the range <limit>..<head>.

     The equivalence test is based on the diff, after removing
     whitespace and line numbers. git-cherry therefore detects when
     commits have been "copied" by means of git-cherry-pick(1),
     git-am(1) or git-rebase(1).

     - git-cherry(1)

-Bryan
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs