[GuB-42]

A unit of contribution is always a branch, implicitly or explicitly. What you have in your local repository is a branch of what is in the central repository, which is a branch of what you have in your filesystem, which is a branch of what you have open in your editor. In the same way a contribution is always a merge, saving a file is merging the content of your editor in your filesystem, committing is merging your file in your local repository, and pushing is merging your local repository with the central repository.

That's git main insight, branching is everywhere, so it is designed with branching and merging as fundamental, explicit, and regular operations. Seeing how successful git is, it looks like it was a good choice.

GitHub and GitLab are built on top of git, and follow its principles, so that making the branch the unit of contribution is simply natural.

Of course, you can make single commit branches, in fact, that's what squashing is for. There is, of course, no obligation to wait before you have your change merged before you start working again, you can start from an earlier version and rebase later, merge back some changes, or do whatever you want really. You can tight-loop as much as you want, especially on your local machine.

[mhh__]

The way (say) the kernel uses branches is not very similar to the way GitHub does it where you actually push a branch and then let the machine do the merge

It's the same ingredients but it's very hamfisted.

Squashing is like training wheels.

What I was hinting at with the loop concept is that it should be closer to phabricator that gitlab, let me stack.