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

51–60 of 454 posts

Re: Why SQLite does not use Git (2018)

#51

Post by maxxk »

avgjo wrote: post #38

I've used Fossil for a private local project. It's quite a capable revision control system with a very decent web UI. Just a word of warning - make frequent backups of the backing sqlite repository database. I had upgraded fossil to make a few commits and then I inadvertently made a commit using an older version of fossil and it corrupted the fossil repo database irreparably and a few days' of work was lost. I've nev…

Is it a known behavior? Considering SQLite developers approach to reliability, I think it would count as a critical bug worth fixing.

Re: Why SQLite does not use Git (2018)

#52

Post by osigurdson »

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…

Well, it’s either a single executable in a container or a bunch of dlls/sos in a container.

Re: Why SQLite does not use Git (2018)

#53

Post by forrestthewoods »

jayski wrote: post #37
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…

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’m so thankful that Rust is helping popularize the solo exe that “just works”.

I don’t care if a program uses DLLs or not. But my rule is “ship your fucking dependencies”. Python is the worst offender at making it god damned impossible to build and run a fucking program. I swear Docker and friends only exist because merely executing a modern program is so complicated and fragile it requires a full system image.

Re: Why SQLite does not use Git (2018)

#54

Post by hprotagonist »

forrestthewoods wrote: post #49
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 do it well If only Git did it well! Ok that’s not fair. Git is pretty okay for the Linux open source project. But it’s pretty mediocre-to-bad for everything else. The D is DVCS is a waste of effort. Almost all projects are defacto centralized. In fact the D is anti-pattern that makes things like large binary files a still unsolved problem in Git. And no Git LFS doesn’t count. Source control should be capable fo…

> The D is DVCS is a waste of effort.

until the de facto centralized remote goes offline and you’re stuck with no local history …

Re: Why SQLite does not use Git (2018)

#55

Post by beebmam »

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…

If you're using TLS/crypto in an app, it's scary to statically bundle those libraries.

Re: Why SQLite does not use Git (2018)

#56

Post by no_wizard »

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…

Monolithic builds are great if you have no control over the deployed environment (IE desktop apps sans OS supplied libs). They’re worse if you do control the environment and how the upgrade paths get followed

Re: Why SQLite does not use Git (2018)

#57

Post by Brian_K_White »

NBJack wrote: post #7

I think there are some legitimate criticisms of Git here. But some of them are...odd. Despite using Git in a variety of circumstances, from a local personal repo project to very large company repos, I admit I haven't run into about half of these issues. > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on…

There are all kinds of non-optimal optional ways to do things where it's valuable to have the options and have them work as well as possible vs not having the option.

I guess it falls under graceful degrade vs die.

It doesn't matter how much better the proper gold plated option is. If it's the only option then it's fragile and that makes it garbage.

Re: Why SQLite does not use Git (2018)

#58

Post by LordShredda »

hprotagonist wrote: post #54
forrestthewoods wrote: post #49

Earlier quoted context omitted.

> and do it well If only Git did it well! Ok that’s not fair. Git is pretty okay for the Linux open source project. But it’s pretty mediocre-to-bad for everything else. The D is DVCS is a waste of effort. Almost all projects are defacto centralized. In fact the D is anti-pattern that makes things like large binary files a still unsolved problem in Git. And no Git LFS doesn’t count. Source control should be capable fo…

> The D is DVCS is a waste of effort. until the de facto centralized remote goes offline and you’re stuck with no local history …

Not an issue, if remote goes down you can always restore from backup

Re: Why SQLite does not use Git (2018)

#59

Post by somenewaccount1 »

>Git focuses on individual branches, because that is exactly what you want for a highly-distributed bazaar-style project such as Linux. Linus Torvalds does not want to see every check-in by every contributor to Linux: such extreme visibility does not scale well. Contrast Fossil, which was written for the cathedral-style SQLite project and its handful of active committers

Ugh...so after all that fanfare of how amazing fossil is, the author admits it just doesn't scale well. I was wondering how that "see it all" approach worked for a busy repo, and now I know, it just doesn't.

I love SQLite, and glad the primary author is happy working on it with fossil. I think if he published it's largest downfall first, it might gain more adoption to folks that could actually use that feature.

Re: Why SQLite does not use Git (2018)

#60

Post by cosmojg »

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…

> The only argument I buy is: "2.6. Git provides a poor user experience," and the xkcd is not an exaggeration.

Oh no. I'm the guy in the alt text. Should I be concerned?

Post reply on HN