Re: Gitlab workflow

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 > : > > > [...] When references to commits (in emails etc.) get invalidated, > > it adds confusion and extra work. Seeing this happen is

Re: Gitlab workflow

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

Re: Gitlab workflow

Am Do., 11. Juli 2019 um 14:32 Uhr schrieb Bryan Richter : > [...] 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

Re: Gitlab workflow

On 7/7/19 7:53 PM, Sven Panne wrote:> Am So., 7. Juli 2019 um 17:06 Uhr schrieb Bryan Richter : > > 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 > >

RE: Gitlab workflow

Simon Peyton Jones via ghc-devs 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

Re: Gitlab workflow

Am So., 7. Juli 2019 um 17:06 Uhr schrieb Bryan Richter : > 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

Re: Gitlab workflow

On 7/6/19 11:22 PM, Sven Panne wrote: Am Sa., 6. Juli 2019 um 19:06 Uhr schrieb Bryan Richter : [...] Rather than argue against GHC's current practices, however, I would like

Re: Gitlab workflow

Am Sa., 6. Juli 2019 um 19:06 Uhr schrieb Bryan Richter : > [...] 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

Re: Gitlab workflow

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 clarify

Re: Gitlab workflow

with the Gitlab folk? It seems so egregiously wrong. Simon | -Original Message- | From: Matthew Pickering | Sent: 05 July 2019 10:55 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: Re: Gitlab workflow | | It's not possible to make the MR status merged and also have a reliable

Re: Gitlab workflow

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 >> >> >&

Re: Gitlab workflow

ed 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 > | Sent: 05 July 20

RE: Gitlab workflow

| 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

Re: Gitlab workflow

; Thanks > > Simon > > > > | -Original Message- > | From: Matthew Pickering > | Sent: 05 July 2019 10:39 > | To: Simon Peyton Jones > | Cc: ghc-devs > | Subject: Re: Gitlab workflow > | > | Hi Simon, > | > | No it is not possible due to

RE: Gitlab workflow

figure out which one to believe? Thanks Simon | -Original Message- | From: Matthew Pickering | Sent: 05 July 2019 10:39 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: Re: Gitlab workflow | | Hi Simon, | | No it is not possible due to the use of Marge to merge patches. Gi

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,

Gitlab workflow

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