> Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews? GitLab (I know it works, because I set u

> Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews? GitLab (I know it works, because I set up this workflow in my company). Before GitLab: Phabricator, Gerrit. > All the git operations you listed work perfectly fine locally on a repo from github ... Irrelevant. GitHub needs to be compatible with Git, not the other way around. This subthread began with the assertion that GitHub wants to break that dependence. > Gitlab works mostly the same as Github False. GitLab lets me compare different versions of the same MR against each other. Without extra work. It's right there in the MR diff UI. That's literally what I wanted. > ... for both of them you can configure the merge-strategy and PR requirements per repo. Some configuration allowed. Not the same kinds. GitLab's squash-and-merge strategy actually works, even lets me set the commit message! GitHub built their incomplete implementation of sth similar only recently, to catch up with GitLab, but also stopped half-way. That last bit is what gives rise to the suspicion that started this thread: that GitHub doesn't really want to be Git-compatible and doesn't care about Git. GitLab, OTOH, introduced this feature, a long time ago, because it saw people were already using Git this way. I couldn't accept doing development in my company without some kind of auto-squash support. > which is more based on single commits rather than branches and pull-requests, but in a way their refs/for/master is very similar to a PR except it doesn't have a branch-name Gerrit has branch names, I don't know what you're talking about. In fact, it has better support than GitHub. I can push a locally created branch and ask for the branch to be reviewed, all from the `git` CLI. I can even change the branch name, push the new branch, delete the old branch (on remote, from local `git` CLI) and all of my changes and their reviews remain intact! The equivalent on GitHub would require me to close my current PR and open a whole new one! > and you don't need to fork the repo first This is a good thing. `git clone` is already a fork. I shouldn't have to make two forks, one of them through some external interface, and another through the `git` CLI, just to be able to work on sth. Git's branches are already excellent, there's no need for yet another way to keep separate versions of a repo. > but under the hood you could say a patchset on a change is the same as a commit on a branch sent for PR. No. I think your understanding not Git derives almost entirely, if not predominantly, from GitHub. And this is exactly what we're talking about in this thread. GitHub would like to impose their way of doing things on everyone, irrespective not what better ways exist (and have existed since before GitHub was born). In Gerrit, each change is a commit on a branch. There are versions of commits, each of which is a patchset. This is good and desirable, because it leads to cleaner branches. I like this, I want this, and I've been using this since before GitHub was launched. GitHub's only supported way is to create a commit for every tiny edit, irrespective of whether it's significant enough to be enshrined forever in the final branch as an independent commit of its own. This adds noise. Buncha commits with just the message 'Typo'. Ugh. Imagine running into one of these in a git blame, months later. Imagine looking at a git log. Just ugh. And what's the alternative with GitHub? Squash all commits in a PR into a single one. So now I can't have more than one significant commit in the same PR. Okay, fine, whatever; can I at-least make one PR dependent on another one, like a commit that has a parent? Nope! > In the end, they are all the same and you learn to work with it. As I show above, they're not all the same. Can't learn to work with sth you need that's missing. > None of them really fight against the core of git. If I can just git push and git pull and get all my work done with just that, then yeah, none of them really fight against the core of git. But then why would I use them instead of a headless SSH server? They all fight against Git, in different ways, when they decide to build custom UX for one workflow or the other. They're telling you what workflows they support. If your workflow can't fit into them, well then they can't do the job you want them to. This is why both Gerrit and GitLab were built the way they are today: their users needed a certain workflow (feature) and they cared enough about those users that they grew to support such features. GitHub has ... other users ... it cares about more. Not the power users. But power users also are more likely to be defiant, to resist control.