Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why SQLite does not use Git (2018)

sqlite.org

Post reply on HN
Print view View original

111–120 of 454 posts

Re: Why SQLite does not use Git (2018)

#111

Post by westurner »

qbasic_forever wrote: post #101
thayne wrote: post #98

Earlier quoted context omitted.

FWIW, that isn't actually part of the core git binary. Because unlike fossil, git is a collection of executables, not just one.

Yes, which is why git is a pain in the butt to install and you have to rely on your OS packages (which includes all the kitchen sink stuff) or a GUI installer with all the necessary dependencies vs. Fossil which is just download executable and done.

Securing the software supply chain for software updaters and VCS systems means PKI and/or key distribution, cryptographic hashes and signatures, file manifests with per-archive-file checksums, and DAC extended filesystem attributes for installed files; Ironically, there's more to it than just `curl`'ing a binary into place and not remembering to update it.

And that is why package managers.

Re: Why SQLite does not use Git (2018)

#112

Post by velcrovan »

ohthatsnotright wrote: post #21

I'm glad Fossil works for them, but this line is bothered me: > In contrast, Fossil is a single standalone binary which is installed by putting it on $PATH. That one binary contains all the functionality of core Git and also GitHub and/or GitLab. It manages a community server with wiki, bug tracking, and forums, provides packaged downloads for consumers, login managements, and so forth, with no extra software require…

And yet, because git does not bundle those things, which actually do belong as part of a modern SCMS, people lock themselves into GitHub or Gitlab, which provide those missing pieces.

Re: Why SQLite does not use Git (2018)

#113

Post by jpeeler »

kasperset wrote: post #106

I saw this video few days ago which describes some of the alternative to Git and of course Fossil is one of them. I have used Fossil in some projects and found to be ok. I found Pijul https://pijul.org/ described in this talk to be very interesting. It was discussed on HN before. Source: https://www.youtube.com/watch?v=M4KktA_jbOE

I'm still trying to wrap my head around this one, but jj is interesting: https://github.com/martinvonz/jj

Re: Why SQLite does not use Git (2018)

#114

Post by dmvdoug »

devin wrote: post #45
ohthatsnotright wrote: post #21

I'm glad Fossil works for them, but this line is bothered me: > In contrast, Fossil is a single standalone binary which is installed by putting it on $PATH. That one binary contains all the functionality of core Git and also GitHub and/or GitLab. It manages a community server with wiki, bug tracking, and forums, provides packaged downloads for consumers, login managements, and so forth, with no extra software require…

the more important takeaway imho is that the tooling doesn't really matter, but i hear you.

Outsider here.

One thing that I have observed about programmers is how obsessed they are with tooling. Whether it’s exactly which model of ergonomic keyboard or exactly which toolchain(s) they’re using, there seems to be an endless desire or eagerness to shoot the shit over tooling.

Re: Why SQLite does not use Git (2018)

#115

Post by nickpsecurity »

op00to wrote: post #47
maxxk wrote: post #42

Earlier quoted context omitted.

> git, for all its issues, is not bundling the kitchen sink. It doesn't bundle the kitchen sink in its native *nix environment, but for Windows it does. Git installer is > 50 MB, including (if I remember correctly) even a terminal. While you can download Fossil as a 3.3 MB standalone binary for any supported platform.

I don’t develop on a machine where this matters, even at scale. Who cares about a 47MB difference on machines with a few gigs of ram?

I used to try to make tools fit in cache, esp L1, because they'd load and run a lot faster. Lightening fast!

Try that to see if it still works on the newer machines.

Re: Why SQLite does not use Git (2018)

#116

Post by velcrovan »

thayne wrote: post #95
blagie wrote: post #46

Most of these arguments are nonsense. "Standing up a git server is non-trivial." It's literally just "git init" and providing ssh access to the directory. Most of the other ones seem to suggest the author never learned git. git has a beautiful data model and a horrible user-space to poke at it. Writing a new user-space makes sense. This seems to poorly re-invent the data model, by virtue of not bothering to understan…

It is non-trivial to stand up a redundent, highly-available, and scalable git server. And if you throw in "with a good web interface", even moreso. But I doubt that is trivial to do with fossil either.

What do you mean by redundant, highly available? Under what circumstances are those necessary? Whatever it is, seems completely orthogonal to version control software. Anyways, I can serve a fossil repo with a great web UI and a few 9s of reliability on an existing web server with literally a 2-line CGI script.

Re: Why SQLite does not use Git (2018)

#117

Post by yjftsjthsd-h »

forrestthewoods wrote: post #88
kstrauser wrote: post #62

Earlier quoted context omitted.

Or on a plane. It’s nice to have 100% of its functionality when you have 0% of your usual connectivity. Branches, commits, merges, all from the local file system? Yes, please. There’s a reason we moved off centralized VCS en masse.

Sorry, but you’re completely and objectively wrong. This is a huge misnomer. Distributed and “offline support” are fully orthogonal features. Distributed means every user has a full copy of the entire repo including full history. This is a radical and unnecessary limitation on the scope and size of source control. You can have full support for branching, commits, and merges without a fully distributed repo. There are…

> Distributed means every user has a full copy of the entire repo including full history.

Then git must not be a DVCS; I use shallow clones all the time.

In any event, centralized systems probably can do offline support, at least in theory, but DVCSs more or less include it for free by default, which is still worth something.

Re: Why SQLite does not use Git (2018)

#118

Post by genocidicbunny »

gorjusborg wrote: post #99
forrestthewoods wrote: post #91

Earlier quoted context omitted.

Git is a “distributed version control system” (DVCS). You’re just adding the term “source code” for no particular reason. I make video games. Video games contain far more data than mere source code. Almost all game devs use Perforce because Git is insufficient. Artists and designers desperately need more version control in their lives. They are mostly absent because their programmers use Git which is insufficient. It…

Seems like you are just complaining that something useful to a great many people isn't perfect for you particular use case. Use something thats's a better fit for your use case. There's nothing wrong with a hammer, you just want a screwdriver.

Except it seems the world keeps insisting that I use the hammer to bash on the screws.

Re: Why SQLite does not use Git (2018)

#119

Post by taneq »

maxxk wrote: post #42
ohthatsnotright wrote: post #21

I'm glad Fossil works for them, but this line is bothered me: > In contrast, Fossil is a single standalone binary which is installed by putting it on $PATH. That one binary contains all the functionality of core Git and also GitHub and/or GitLab. It manages a community server with wiki, bug tracking, and forums, provides packaged downloads for consumers, login managements, and so forth, with no extra software require…

> git, for all its issues, is not bundling the kitchen sink. It doesn't bundle the kitchen sink in its native *nix environment, but for Windows it does. Git installer is > 50 MB, including (if I remember correctly) even a terminal. While you can download Fossil as a 3.3 MB standalone binary for any supported platform.

"You're using Windows so you obviously want an entire mini-Cygwin type environment for your source control software"

Re: Why SQLite does not use Git (2018)

#120

Post by MuffinCups »

bane wrote: post #41
jayski wrote: post #37

Earlier quoted context omitted.

I think SQLite is fantastic and Richard is obviously a genius. But I always found his obsession with single binary monoliths odd. As you mentioned it goes against the Unix philosophy of do one thing and do it well. To me it's obviously cleaner to divide a system into components that can later be swapped or modified independently.

I have no idea why Richard focuses on such things but: I'm old enough to remember when developers spent time making sure they could plow all of their build assets into a single binary distributable. It often had kind of a zest to it and when you dealt with software had directories full of stuff it looked both "corporate" and "sloppy". I've never quite gotten over the feeling that the piles of dynamically linked libra…

A dynamically linked library need only have one image of itself in memory.

If you are running a process that, for example, forks 128 of itself, do you want every library it uses to have a separate copy of that library in memory?

That's probably the biggest benefit. But it also speeds up load time if your executable doesn't have to load a huge memory image when it starts up, but can link to an already in-memory image of its library(s).

The only real downside is exporting your executable into another environment where the various dynamic library versions might cause a problem. For that we have Docker these days. Just ship the entire package.

Post reply on HN