[lmm]

The fears are legitimate. Both rebase and force-push can lose data in some circumstances, which merge and push cannot. Yes, there are strategies which, if followed perfectly, allow one to avoid losing data when doing rebase and/or force-push. But those strategies are not simple to describe, especially to newcomers, and in practice people make mistakes; all else being equal, an inherently safe workflow is better.

[imiric]

> The fears are legitimate.

They're really not.

First of all, no data is really lost with Git. Commits can be recovered from the reflog if they haven't been garbage collected, and there are ways of recovering anything on GitHub as well[1], even if it technically shouldn't be the case.

But this aside, data loss is circumstantial, like you say. I've heard the idea that force-pushing in general is harmful, when it's really not if you're working solo or on an isolated branch. Rebasing and force-pushing are just different tools in the toolbox.

In general, my objection is to the practice of describing any software as "dangerous". It creates an air of intimidation that prevents people from using the tools to their full extent, which when spread can popularize wrong practices among new users as well. This is why you see the person in the article claiming that they've always been a "merger", having a false dilemma between merging and rebasing, and describing their solution as "fearless". This line of thinking is also commonly associated with the command line and Linux itself, and is just harmful.

Instead, users should be educated on what the software does, which does require having comprehensive UIs and documentation, and designing the software with sane defaults, fail-safes, and ways to undo any action. Git doesn't do a great job at all of these, but overall it's not so bad either. What really hurts users is spreading the wrong kind of ideas, though.

[1]: https://neodyme.io/en/blog/github_secrets/

[lmm]

> First of all, no data is really lost with Git. Commits can be recovered from the reflog if they haven't been garbage collected

So no data is really lost except when it is.

> I've heard the idea that force-pushing in general is harmful, when it's really not if you're working solo or on an isolated branch. Rebasing and force-pushing are just different tools in the toolbox.

Like I said, there are specific circumstances where you can do it safely. But that's very different from being safe in general.

> This is why you see the person in the article claiming that they've always been a "merger", having a false dilemma between merging and rebasing, and describing their solution as "fearless". This line of thinking is also commonly associated with the command line and Linux itself, and is just harmful.

> Instead, users should be educated on what the software does, which does require having comprehensive UIs and documentation, and designing the software with sane defaults, fail-safes, and ways to undo any action.

Users can't and won't learn the full details of everything they use, especially "secondary" tools that they use to support their main workflow - and why should they, unless the benefits are large enough to justify that cost? Using a tool in a mode that is inherently safe rather than a mode that can cause data loss in some circumstances is a perfectly reasonable choice. "Fearless" and "dangerous" are perfectly reasonable ways to characterise this distinction.

[imiric]

> So no data is really lost except when it is.

The period before inaccessible objects are pruned automatically is quite relaxed by default (between 2 weeks and 90 days, depending on the object), and it is configurable. So the scenario we're discussing here where data is lost by a force-push is just not a practical concern.

> Like I said, there are specific circumstances where you can do it safely. But that's very different from being safe in general.

No, force-push is safe _in general_. It is a bit inconvenient to recover the inaccessible commits if someone makes a mistake, but this doesn't make rebasing or force-pushing unsafe.

> Users can't and won't learn the full details of everything they use, especially "secondary" tools that they use to support their main workflow

Huh? How is Git a "secondary" tool for a programmer? It is an essential part of the programmer's toolkit as much as an editor is, and understanding and being proficient with both is equally important. Users in this case should be expected to learn the tools they will be relying on for a large part of their career. Compared to the complexity of programming environments, stacks and languages we deal with on a daily basis, this tooling is fairly simple to grasp.

I'm not saying that Git doesn't have issues that can't be improved—it certainly does—but in the grand scheme of things it is a simple, reliable and well-engineered piece of software.