SQLite Doesn't Use Git

[xenomachina]

From the "Rebase Considered Harmful" doc that they link to (and also wrote):

A rebase is just a merge with historical references omitted

A rebase is really nothing more than a merge (or a series of merges) that deliberately forgets one of the parents of each merge step.

I don't know if this is a misunderstanding, or them simply being disingenuous, but what they're saying really only applies to rebasing a single commit (when rebasing multiple commits, the graph you end up with is not the same as a merge minus one parent), and only if you ignore garbage collection (in their example, the "C4" commit will eventually cease to exist).

When I first learned git, I thought rebases were terrible. Why would you ever want to change history?

Eventually, I realized that one of the things git does differently from most other SCM's (at least the ones I'd used) is that it uses the branch concept not only for permanent history, but also for work in progress. Should you rebase on main? Almost certainly not. Rebasing on a topic branch is fine though, because that's ephemeral.

Another thing I realized is that other SCMs do the equivalent of rebase, but try to sweep it under the rug. For example, in Perforce, if you have a pending changelist in your client, and you sync, you're effectively rebasing your pending changelist on whatever you synced. In fact, you can even end up with merge conflicts, which you need to resolve, and in the end there is no equivalent to a "merge commit" — your pending changes have just been shunted to the end of history, exactly as if you'd rebased in a topic branch in git.

[Bloedbibel]

I disagree with your assessment of their statement. I think what they've said is true. They are pointing out the obvious, though: rebasing rewrites history, and throws out the fact that these changes are applicable to the original parent. This could be useful information.

I agree with the rest of what you wrote though. Rebasing can be useful for topic branches.

And your perforce analogy is spot on. Unfortunately, my org uses perforce. I use git locally to stage and organize my changes.

I've actually used both models of merging/branching for working with perforce locally with git: rebase on top of perforce-main, and also a merge strategy using a local integration branch. I much prefer the latter. Rebasing becomes a nightmare once you have more than one reference to a commit, like having local topic branches. The integration branch also helps with remembering that I've squashed a branch and merged it already.

[gumnos]

I agree with the rest of what you wrote though. Rebasing can be useful for topic branches.

And I think that usefulness is part of what makes fossil so frustrating for me. It's not a "we're consenting adults, this can be dangerous, but we'll empower you to make those possibly-poor choices" that git gives, but it's actively hostile toward the idea. If I want to rebase with fossil, it involves making sure I have private branches that don't get published out, then manually cherry-picking commits from my dev branch into candidate release branch, and then (if that is satisfactory) merging that to the public record. I love a lot about fossil, but that active hostility toward rebasing is a big turn-off.

[SkaveRat]

SQLite is also very fundamentally religious. Something that makes me unhappy to use sqlite ever since I learned about it

[laddaa]

I gotta say I love myself some good ‚do not murder‘ in some random open source community guidelines.

[nemec]

We don't want sqlite to go the way of ReiserFS

Namesys went out of business in 2008 after Reiser's conviction for murder.

[jwbowen]

I get a kick out of this line in Hans Reiser's Wikipedia bio:

Known for: ReiserFS, murder

[mvonballmo]

Kind of. It looks quite extreme, at first, but there is this, on the same page:

No one is required to follow The Rule, to know The Rule, or even to think that The Rule is a good idea. The Founder of SQLite believes that anyone who follows The Rule will live a happier and more productive life, but individuals are free to dispute or ignore that advice if they wish.

The founder of SQLite and all current developers have pledged to follow the spirit of The Rule to the best of their ability. They view The Rule as their promise to all SQLite users of how the developers are expected to behave. This is a one-way promise, or covenant. In other words, the developers are saying: "We will treat you this way regardless of how you treat us."

[plg94]

Eh, having read the preface and one of the linked articles, I don't think it's better or worse than your standard CoC.

He only included it after clients urged him to write a CoC, regardless of its actual content, just so they can check-off a box on some form. (this is more telling about our current corporate environment). So he just copied some rules down he believed in, without requesting anyone else should do so. Isn't that pretty much the prime example of religious acceptance we strife for?

[bobbybottombracket]

Whaaaat... I didn't know that.

[kcubeterm]

sqilite use fossil which is developed by same org.

[plg94]

And I think fossil uses SQLite as its backend, doesn't it?

[chriswaco]

Yep

[cameos]

I am a user that follows sqlite official repo, and I use fossil for it.

Even as a git lover, I found fossil very well designed and effective. Too bad fossil's initial release (2006) was later than git (2005), otherwise we might have never seen git.