It's Hipp to be square: What happened when SQLite creator met GitHub

The mind behind the SQLite open-source database and Fossil SCM bug-tracking system had a lot to say about his recent meeting with the GitHub team. Dr Dwayne Richard Hipp was invited to a GitHub Open Source advisory board last month, where he had what he described as a "productive meeting" with staff and others. "I was the only …

[Sitaram Chamarty]

rebase is important and useful

Preventing rebase on a published set of commits is one thing, denying it completely in private branches -- before they're published -- is quite another.

I do recall reading about this "fossil" a few years ago, and I do remember backing off and pretty much ignoring it after that when I saw that the lack of rebase was a point of pride for that author.

There are kinder, gentler, ways to prevent rebase on a server, such as running `git config --global receive.denyNonFastForwards true`, without throwing the baby out with the bathwater and preventing its use on developer-local clones.

[Charlie Clark]

Re: rebase is important and useful

But he didn't say get rid of it entirely, he just said he considered it harmful and I think the configuration example you quote is one of the reasons why.

[Sitaram Chamarty]

Re: rebase is important and useful

Maybe not in the interview/article referred here; I was going by my memory.

So I did some digging: here you go... "Rebase Considered Harmful" -- https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

Also, https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#devorg very proudly (my interpretation) says "There is no rebasing mechanism in Fossil, on purpose".

Believe me, this guy is not shy about his hatred of rebase :)

[Marco Fontani]

Re: rebase is important and useful

I can't understand what's wrong with rebase, either on public branches or on private branches.

We use it for _both_ all the time.

The only thing that should be fast-forward only is master. Period. Everything else is fair game.

[Michael Wojcik]

Re: rebase is important and useful

You need to discard part of the merge history "all the time" on public branches? I have to side with Hipp on this one; that sounds like bad practice, frankly.

Pretty much all the rebase use cases I've ever seen boil down to "Shit, I've made a mess. How can I pretend to the world that didn't happen?" Maybe there are good use cases for it, but I haven't seen any examples.

[Sitaram Chamarty]

Re: rebase is important and useful

If you haven't pushed it to anyone yet, rebasing to fix minor issues is perfectly fine. There's no earthly reason not to clean up a commit series before pushing it to the world. In fact, a clean commit series helps the other guys understand what you did better (e.g., rather than seeing commit 9 with something that puzzles them, not realising that commit 13 has a 1-word change that resolves that puzzle with a "doh!", they see commit 9 all correct and proper, say "good", and move on to commit 10).

Rebasing something that's already pushed is, of course, very bad. But that's no reason to ban rebase completely, which -- even if this particular articles does not indicate, this "Hipp" person definitely implements in his "fossil" product.

[Dr_Barnowl]

Re: rebase is important and useful

The best use of rebase is to tell a story in your commit history.

"These changes do this, these changes follow in from that"

We all know that doesn't always happen organically. If you want these stories in your commit history you either A) have to be a galaxy brain genius B) avoid committing until you're "done" which sucks and leads to unrecoverable code fubars C) use rebase

[Pascal Monett]

"GitHub has to be both independent and neutral"

Excuse me, but if that were actually true, GitHub would not have let itself be borged by Microsoft.

Ergo, that is a lie.

Personally, I do not understand what made them accept being bought. Microsoft did not need to buy them in order to use the platform, and Microsoft does not need another paltry few million to pad its already well-padded coffers.

Of course, being showered with billions was most probably a very nice incentive, but if you're all about independence and neutrality, then you stay the course and remain independent. GitHub was not in need of money, so it's just basic greed that made them sell out.

[Charlie Clark]

Re: "GitHub has to be both independent and neutral"

Personally, I do not understand what made them accept being bough

The investors decided to cash in: GitHub was (and probably still is) losing money at the time. Microsoft wants as many people using VS Code, Azure, etc. as possible. It is also probably hoping to integrate user data with LinkedIn.

[Teiwaz]

Re: "GitHub has to be both independent and neutral"

It is also probably hoping to integrate user data with LinkedIn.

That's why I checked out permanently when they 'became part of the microsoft family'

creepy, creepy linkedin.

[Anonymous Coward]

Re: "GitHub has to be both independent and neutral"

Haha. When the party is over you have to pay the piper.

[phuzz]

Re: "GitHub has to be both independent and neutral"

And we know who has all the best tunes....

[JohnFen]

Re: "GitHub has to be both independent and neutral"

"Personally, I do not understand what made them accept being bought. [...] GitHub was not in need of money, so it's just basic greed that made them sell out."

So then, you really do understand what made them accept being bought.

[Anonymous Coward]

product-specific compilers, product-specific SCMs...

... I don't see a bright future for IT - but brainwashed people won't notice it.

The average quality of software is down - while developer spend more time moving their code to the latest toy than making it really useful.

[K]

Re: product-specific compilers, product-specific SCMs...

You've hit the nail on the head...

I highly recommend an experiment to everyone, install a decent Firewall on your PC that alerts for HTTP calls made by each application. Notice how they all have half-dozen calls to SaaS "data collection" and "Error reporting" systems.

These days, I explicit block...

[JohnFen]

Re: product-specific compilers, product-specific SCMs...

"These days, I explicit block..."

The insane trend for software to phone home has made me even more strict with my firewall rules. All outgoing traffic is blocked by default, and I selectively allow programs to talk in a restricted way if needed, on a case by case basis.

[Michael Wojcik]

Re: product-specific compilers, product-specific SCMs...

The average quality of software is down

Do you have any actual (methodologically sound) evidence for that? When was this prelapsarian age of high-quality software? I've been in the business for several decades, and I don't recall it.

[Will Godfrey]

Biassed much?

He has an interest in, nay, is the author of a competing version control system - nuff sed?

[Charlie Clark]

Re: Biassed much?

I think the idea is that GitHub itself seems fairly "meh" about a key component of its platform. Git is far from perfect but Github is now, and probably always was about, the environment around it.

So, the question might be, if GitHub and, by extension Microsoft, isn't going to care about git, then who is?

[JohnFen]

Re: Biassed much?

"So, the question might be, if GitHub and, by extension Microsoft, isn't going to care about git, then who is?"

Everyone who uses git, maybe? There are a lot more people using git than are using GitHub.

[Notas Badoff]

Re: Biassed much?

The fact that he explicitly favours a different SCM - created by himself - is okay. The fact that he seems ignorant of / unacquainted with git's history and development is surprising. Quite strange in fact since he is in equivalence with Linus. You'd think he'd know more.

That his skunk works project does not have the fame and community of that other skunk works project would, I'd have thought, made Hipp a bit more careful in how he mentions criticisms.

Knowledge of git's history and progress should have given understanding of how things can proceed. To scratch an itch (and replace some other shit) it was developed quickly as something better. It was a good enough design to be useful. Gaps were filled in by others as time elapsed. Not different from any other open source project.

Now somebody stumps over and says big money corporations "should make git better!" Wha? Is this the VSCode or the React community wagging tails waiting for more treats? Are people really saying git should be driven by the needs of corporations?

If there are problems with an open source tool that need to be addressed, you know what to do. Communicate, cooperate, consensus, implement, benefit. Wishing to skip to the last step has little merit. Advocating for that is very very disturbing.

[Sloppy Crapmonster]

Re: Biassed much?

GitHub isn't a version control system.

[phuzz]

Re: Biassed much?

You can use it as a version control system though.

Not that that's saying much, you can use Windows as a web server but.....

[Sloppy Crapmonster]

Re: Biassed much?

My hand is not a hammer. My hand is what I use to wield a hammer, with which I drive nails.

Github is not a version control system. Github is what I use to host my Git repositories, with which I control my versions.

A metaphor is a glorious thing. A diamond ring. The first day of Summer.

https://www.youtube.com/watch?v=N8t-drxVvyA

[IGotOut]

Re: Biassed much?

"He has an interest in, nay, is the author of a competing version control system - nuff sed?"

If you note he was invited to have his say.

If you only listen to people that agree with everything you do, eventually you stagnante and die.

If you are willing to listen and even possibly implement alternative views, it can hopefully help you improve.

[JohnFen]

Re: Biassed much?

"If you only listen to people that agree with everything you do, eventually you stagnante and die"

I would be terrified if everyone I interacted with agreed with everything I say and do. I rely on others to point out when I'm I'm wrong and haven't noticed. If my world were full of people who agreed with me on everything, I'd do worse that stagnate and die -- I would be actively getting more stupid with each passing day.

[Someone Else]

@IGotOut -- Re: Biassed much?

If you only listen to people that agree with everything you do, eventually you stagnante and die become a MAGAT.

There, FTFY

[Anonymous Coward]

I hate Git

... but I hate it a bit less than the alternatives (caveat - the alternatives I'VE TRIED)

[cdegroot]

Hardware, operating systems, version control, what's next?

When I started in the industry, everybody made their own chips - then Intel won. At least, everybody still made their own operating systems - then Linux won (at least in my current line of work, SaaS/Cloud style stuff - but that seems where we're all moving). They go under the heading of "solved problem" coupled with "80% is good enough" (or "less is more", if you want to), and that's it.

I've been using tons of version control systems, starting with RCS and ending with Git. Git is the first one to qualify as "good enough", there are usually bigger fish to fry in any development team, so everybody starts using Git (including MS, and I think pretty much for the same reasons).

I wonder when that'll happen with programming languages as well. Most of them are roughly similarly productive, with a large group clustering around "fast for computers, somewhat slower for humans" (C, C++, Java, Golang, Rust, ...) and a large group sitting at "fast for developers, somewhat slower for computers" (PHP, Ruby, Python, these days Elixir - although the latter is only marginally slower for computers). And of course, the front-end lingua franca, Javascript. There's really no differentiator anymore for a team to choose any of these, none of them will - if you're brutally honest - get in the way of success although some of them will make for a more fun time than others (and some of them in the hands of an unskilled team will make a mess much quicker than others).

It's a sign of maturity, in my opinion. People learn to leave their tech religions at home and have a somewhat more realistic look at the sort of tools that make a real difference for a team. And often, they rightfully conclude that "it just does not matter". We've mostly made that decision for hardware, operating systems and clearly version control; I'm curious what's next.

[BlueTemplar]

Re: I hate Git

Which ones ?

Have you tried Pijul yet ?

Its Patch-based model fixes the issue of cherry-picking being fundamentally broken in Directed Acyclic graph models like Git (, and I also assume Fossil, Mercurial, etc. ?)

https://tahoe-lafs.org/~zooko/badmerge/simple.html

[Zippy´s Sausage Factory]

So Microsoft embraced git by buying GitHub.

Now they're getting involved in extending it by getting GitHub to complain about it.

Hmm... wasn't there a third e that Microsoft used to love to say was part of this process?

(Dons tin foil hat and wonders if I ought to register tfshub)

[Anonymous Coward]

https://en.wikipedia.org/wiki/Virtual_File_System_for_Git

They already extended it years ago.

[sqlrob]

Rebase considered dangerous

Yes, rebase is dangerous and should only be done on unpushed commits. You can set up a repo to reject anything that rebases.

The setting is available on github and bitbucket in addition to native git, so if you lose history because of a force push, it's on the admin.

[JohnFen]

Exactly right

"This leads to Hipp's second point. "GitHub used to be a Git repository hosting company. But now, they are about providing other software development and management infrastructure that augments the version control. They might as well change their name to Hub at this point," he said."

This is exactly right, and this fact made it easier to abandon GitHub after the Microsoft purchase.

[Anonymous Coward]

It only took me one look at the git documentation to realise I hate it:

https://www.berrange.com/~dan/git/git-mutilate-commit.html

I’m not the only one;

https://xkcd.com/1597/

[Stuart Moore]

Not sure that's fair...

git rerere is perfectly cromulent

[Hans 1]

This is NOT real git documentation! Read carefully, and click the button to generate a new man page.

[Tim99]

A different model to most.

I think that Richard has a point. SQLite is one of the more/most used software projects in the Public Domain. As on their website the software copyright is:-

"Open-Source, not Open-Contribution

SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from unknown persons.

All of the code in SQLite is original, having been written specifically for use by SQLite. No code has been copied from unknown sources on the internet."

They have 3 developers/commiters so, presumably, keeping track of the project is not that difficult, vs the small but quite complex Git hosted BSD project, Dragonfly, which has about 20 times that number.

Caveat: I am now retired, but used SQLite an a number of projects. I still find it useful to do the heavy lifting on the data from a number of large spreadsheets that I am sent as a volunteer ISO assessor.

[BlueTemplar]

Re: A different model to most.

The right tool for the job !

(Git is especially well-suited for large projects with hundreds of "drive-by" contributors... for small projects, more appropriate SCMs are available ?)

[karlkarl]

Why was he talking to Microsoft about Git? He might as well be asking Sourceforge or Atlassian.

He should talk to the actual guys who have the knowledge and drive to improve it (Linux kernel teams?).

[Sitaram Chamarty]

I would love to be fly on the wall at that meeting.

If you look at his "git versus fossil" page, at https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki , you can see it won't be a useful conversation. Heck it might not even stay polite, though I hear the guy who wrote git is now much mellowed than in the old days ;-)

[BlueTemplar]

Because Fossil is equivalent to Git + GitHub rather than just Git ?

[DrXym]

Rebase can be very useful

If I'm working on a feature branch with some other people and I've locally committed stuff and other people have committed AND pushed stuff, it makes for a far neater history if my changes are rebased (i.e. played on top of) the incoming changes. Otherwise it is a dog's dinner of merge points throughout the code.

Additionally there are times where somebody screws up big time and commits something you'd rather didn't exist at all in the history. In which case you may wish to interactively rebase through the history, skipping the things you want omitted.

Rebasing shouldn't be used without knowing what it's purpose is but it definitely has one. In addition, the "rewriting history" argument could apply equally to squash merges. In our organisation we use squash merges for bug fixes and personal work to condense a bunch of BS commits on some branch down to a single commit on the mainline. That reduces a heap of meaningless comment noise and makes it easier to revert the change if needs be. We only preserve history and use merge points when bringing in a large feature, or when we want to merge from the mainline back into the feature.