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 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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Gitlab workflow
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 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 > 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@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 > >>> | 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 > >>> | 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 > >>> | 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
Re: Gitlab workflow
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 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 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 | 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 | 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 | 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 | > | 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. | > | 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
lint-submods-marge consistently failing when attempting to update Haddock
I've noticed that Marge's most recent batch is consistently failing after repeated attempts. Each time, the failure is only in the lint-submods-marge job. Here is an excerpt from the most recent failure [1]: Submodule update(s) detected in 1cd22260c2467650dde8811cc58e89594a016f43: utils/haddock => 658ad4af237f3da196cca083ad525375260e38a7 *FAIL* commit not found in submodule repo or not reachable from persistent branches My understanding is that the lint-submods-marge job checks for any submodule updates, and if there is an update, it ensures that the new commit is actually present upstream. However, I have already pushed Haddock commit 658ad4af237f3da196cca083ad525375260e38a7 upstream on GitHub [2], and there has been enough time for this commit to also appear on the GitLab mirror [3]. Despite this, lint-submods-marge keeps failing, and I have no idea why. Does anyone know what to do from here? Ryan S. - [1] https://gitlab.haskell.org/ghc/ghc/-/jobs/119054 [2] https://github.com/haskell/haddock/commit/658ad4af237f3da196cca083ad525375260e38a7 [3] https://gitlab.haskell.org/ghc/haddock/commit/658ad4af237f3da196cca083ad525375260e38a7 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
