This is false. Well, it can be false. Git sucks and makes it harder then it needs to be.
It’s relatively easy to have multiple people working on a feature branch that is continuously rebased.
Meta’s Mercurial-like VCS system automagically stores 100% of commits in the cloud. Feature branches are anonymous rather than named. It’s all just a tree of commit hashes.
Having multiple people work on one “branch” requires some basic communication as to what is considered “tip”. But since it’s all anonymous there’s no issues with different people incrementing a named branch to different commits.
Honestly it’s pretty simple and easy. Git makes it harder than it actually is.
As far as I can tell, what is really meant by “rebase is only possible for "private" commits.” is that for public commits, rebasing would require to coordinate with everyone interested in that branch.
This seems to be very similar to what you say with “requires some basic communication as to what is considered ‘tip’”
Requiring coordination (or a constrained model of allowed changes) when modifying things (such as what the tip/branch points to) is a general principle unrelated to git and applies to every workflow.
That said, I do understand that Meta’s centralized tool is more useful for your usecase.
> I do understand that Meta’s centralized tool is more useful for your usecase.
One of my chief Git complaints is that 99.9% of projects are de facto centralized on GitHub. Genuinely decentralized projects are vanishingly rare.
The way Git auto-advances branch tags causes a lot of pain. Having lots of people commit to a shared feature branch that has lots of rebasing is quite easy when the “tip” is infrequently updated. Each person thinking they can declare the new tip with every commit is the source of pain.
Again, I see where you are coming from, and I do agree that a lot of discussion about Git (and it’s workflow) is really about GitHub (and it’s workflow).
But even when using GitHub as the hosting service, every time you work on a local branch (this includes main/master) you are working on something purely local that will not conflict with what anyone else is doing.
It’s only by pushing/pulling that tracking branches are automatically updated, which seems to correspond to the operation that you would refer to as updating tip.
As the rest of the discussion is this topic seems to indication, people do work on these “private” branches a lot, and do rebase/modify them freely to create a history as they like before publishing that history (at which point, you would require coordination with everyone who saw that to change it again).
As far as I can tell, what the Meta tooling seems to offer is that you can see the “kinda private” commits of other people, if I understand correctly.
That does sound indeed useful, but also out of scope for Git – rather part of some further UI that displays such information conveniently.
This is false. Well, it can be false. Git sucks and makes it harder then it needs to be.
It’s relatively easy to have multiple people working on a feature branch that is continuously rebased.
Meta’s Mercurial-like VCS system automagically stores 100% of commits in the cloud. Feature branches are anonymous rather than named. It’s all just a tree of commit hashes.
Having multiple people work on one “branch” requires some basic communication as to what is considered “tip”. But since it’s all anonymous there’s no issues with different people incrementing a named branch to different commits.
Honestly it’s pretty simple and easy. Git makes it harder than it actually is.