I don't think it makes any sense to mention source hut because none of the features you mentioned are killer features (or relevant. Why should I care about implementation details of feature tracking?) and it completely fails to address GitLab's main value proposition: it's CICD system.

Anyone can put up any ticketing system. They are a dime a dozen. Some version control systems even ship with their own. CICD is a whole different ballgame. It's very hard to put together a CICD system that's easy to manage and has a great developer experience. Not even GitHub managed to pull that off. GitLab is perhaps the only one who pulled this off. A yams file with a dozen or so lines is all it takes to get a pipeline that builds, tests, and delivers packages, and it's easy to read and understand what happens. On top of that, it's trivial to add your own task runners hosted anywhere in the world, in any way you'd like. GitLab basically solved this problem. That's why people use it.

The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.

I think you got it entirely backwards.

The whole point of Agile is being able to avoid the "big design up front" approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you're picking up along the way.

The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.

It baffles me that you can advertise something as “unlimited” and then impose arbitrary limits after the fact.

I didn't saw anything on the post that suggests that was the case. They start with a reference to a urgent call for a meeting from cloud flare to discuss specifics on how they were using the hosting provider's service, which sounds a lot like they were caught hiding behind the host doing abusive things,and afterwards they were explicitly pointed out for doing abusing stuff that violated terms of service and jeopardized the hosting service's reputation as a good actor.

Git is ugly and functional.

I don't even think it's ugly. It just works and is intuitive if you bother to understand what you're doing.

I think some vocal critics are just expressing frustration they don't "get" a tool they never bothered to learn, particularly when it implements concepts they are completely unfamiliar with. At the first "why" they come across, they start to blame the tool.

Incidentally, this kind of passive-aggressive pressure is the kind of thing that might be considered a legitimate security threat, post xz.

Yes, OP's attempt to bully a maintainer into accepting his PR is a very shitty thing to do.

Throwing veiled personal attacks, such as insinuating a developer is incompetent or dumb, is also very bad form.

This says more about OP than anything. I hope I never have to work with anyone like that. What a shit show of a person.

OP,

Here's a friendly reminder that programming.dev has a community dedicated to .NET: !dotnet@programming.dev

If you need anything more complex than cherrypick, you already screwed up big time.

I think this is a clueless comment. You can use Git to greatly improve your development workflow if you dare going beyond the naive pull/commit/push workflow.

Take for example interactive rebase. It let's you do very powerful stuff such as changing the order of commits in a local branch and merge/squash contiguous commits. This unlocks workflows such as peeling off bugfix and cleanup commits from your local feature branch without having to switch branches. I'm talking about doing something like:

a) - you're working on your task, b) - you notice a bug that needs fixing, c) - you fix the bug and commit your fix, e) - you continue to work on your task, f) - you notice a typo in your bugfix code, so you post a fixup commit. g) - you post a few commits to finish your task, h) - you noticed your bugfix commit didn't had the right formatting, so you post a couple of commits to lint your code both in your bugfix commits and task.

When you feel you're done, you use interactive rebase to put everything together.

a) you reorder your commits to move your bugfix commit to the top of your local branch, followed by the typo fixup commit and the linter commit. b) you mark both the typo and linter commits as fixup commits to merge them with the bugfix one, c) you post a PR with the single bugfix commit, d) you finally post a PR for your task.

Notice that thanks go git interactive rebase you did not had to break out of your workflow or do any sort of context switch to push multiple PRs. You just worked on things you had to work, and in the end you just reorganize the commit history in your local branch to push your work.

Is this what you call "screwed up big time"?

You don’t need any of it, relevant experience is worth in the region of 5x-10x for every hiring manager I’ve known, and for myself.

The only time I had to brush up on data structures and algorithms is when I apply to job ads, and recruiters put up bullshit ladder-pulling trivia questions to pass to the next stage of a recruiting process. It's astonishing how the usefulness of a whole body of knowledge is to feed gatekeepers with trivia questions.

He is completely right in this context, not all European countries have the same workers right as Germany.

I understand that this isn't an academic discussion on logic, but it's also not correct to claim that Europe doesn't have basic worker's rights because there might be a country or two in the dozens of countries that make up Europe that might not have explicitly prohibit a specific form of abuse.

This article seems to be well-meaning but contrasts with the de-facto standard way of storing dotfiles. The Linux Filesystem Hierarchy Standard is quite unambiguous in how it specifies that the purpose of $HOME is to store dotfiles.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s08.html

FHS also specifies that applications can store their dotfiles in subdirectories, and this is leveraged by other standards like the Freedesktop's xdg-user-dirs spec to default to ~/.config

https://www.freedesktop.org/wiki/Software/xdg-user-dirs/

I'm not sure what's the point of arguing against the standard way of storing dotfiles while basing the remarks on no standard or reference.

Is it just me or is this a nightmare implementation in terms of software maintenance and operations? Each state transition requires a database trip, state machine transitions are determined at runtime and there's no simple way to reproduce them locally, and in the case of the state machine database going down the system simply cannot work.

What exactly is the selling point of this approach?

You can’t both be a good meeting-place for experts and a good place for novices to get expert advice and an advertising venue.

I don't agree. There is no clear cutout between what means to be an expert and a novice. What content you're exposed to is the output of the service's support for user profiling and search. It is simply not possible to get rid of an important subset of your customer base without causing false positives and generate ill-will. Finally, we should keep in mind that yesterday's novice is today's expert.