Interesting take, especially if you factor in action on climate change. The US is unable to get anything done, while the EU has a track record of getting results.
As retail investor there's great downsides to market makers too. The prime example; the true price of the underlying is obscure when executing an order. Where the whole point of the market is to create price efficiency. When anyone creates a limit order in the middle of the spread it's often filled instantly, but not market moving. Other investors now do not have the same information as the market makers have who filled the order. So either they should publicly log each trade so all brokers can show what the true last price was and change in positions with that, or PFOF creates information dissymmetry. Markets should be transparent, and if you make money through obscurity that's against what the market is for.
Another problem is that market makers tend not to provide liquidity when it's most needed; when markets are most volatile and unpredictable. The GME spreads for example were very wide. When the market is very volatile they tend to increase the spreads until the market is predictable (as far as they can be) again. Effectively they're like bad insurance companies: When you need them they're nowhere to be found, when you don't they'll gladly take your money.
It's for everyone involved, except ones that make money of PFOF plus the market makers, probably better to have transparent inefficiency in pricing, then have defuse pricing which in some cases might be in your favour.
The issue tracker I think is a better place for such a feature request.
Last time I worked on the attachment code, there wasn't a persistent database relationship for uploads and notes. Which would make this feature hard to implement, it would be a great feature though!
As a hiring manager at GitLab, I'll tell you that these questions are surprisingly effective in filtering candidates. I'm sorry it feels painful to you, however, it's for good reason.
I'm saying the blob was in a new repository, you had no control over. You couldn't have removed it, you could only make sure it doesn't get referenced in _your_ repository. Which is what you did.
The additions GitLab has expand on Markdown. For example, if you comment with a string of hexidecimals larger than 8 characters, GitLab will try to link to the commit if it finds one. For issue 1, the reference pattern in #1. This is convenient in cases where you want to cross reference merge requests, snippets, and others, without copy pasting the links. The docs explain it better than I could: https://docs.gitlab.com/ce/user/markdown.html
But in general, GitLab supports Markdown, with a few extensions.
I've used it a couple of times now not to develop, but to incorporate review discussions and minor other fixes. But from my perspective the true value is for non developers, or when you're starting with Git. No need to worry about remotes and what you did or didn't sync. Or if the branch is even there and you need to set the upstream. Concepts one need to get now are branches and commits. No cloning, fetching, pulling or pushing. When starting, branches and commits are hard enough.
Than, when the new user is comfortable they can work their way up.
The Gitaly server has a Ruby component, but also a Go component. The Ruby server uses Rugged[1] and Gollum-lib[2] which both use libgit2.
The Go component doesn't have libgit2 binding yet, although we're looking into adding that later. That or maybe go-git[3]. But for now Gitaly is mainly focussed at migrating all git calls from the Rails monolith. Not introducing a new component now reduces the risks this project has.