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

41–50 of 454 posts

Re: Why SQLite does not use Git (2018)

#41

Post by bane »

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 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 libraries hasn't helped things. I know objectively that there's a notion that you can update libraries instead of applications, but it feels like it makes updating applications fragile and you inevitably end up in some kind of dependency hell. "But breaking insecure applications is a feature!" I mean, okay, I guess. But I still need something to work and don't want to spend all day fixing broken layers of dependent stuff. If I have to do that, I may as well just update a single binary.

Go seems to have come back around to this style of thinking, and in a sense container images and JAR files are often trying to replicate what it's like to just download a binary, chmod +x it, and execute it.

Re: Why SQLite does not use Git (2018)

#42

Post by maxxk »

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.

Re: Why SQLite does not use Git (2018)

#43

Post by eska »

upon_drumhead wrote: post #19
eska wrote: post #16

Earlier quoted context omitted.

> from people who have not submitted an affidavit dedicating their contribution into the public domain. Don’t spread FUD

Here you go. https://sqlite.org/forum/forumpost/860f855ed144703d > The project requires a document on file but it doesn't accept that document from arbitrary people. It's effectively "by invitation only" and Richard hands out those invitations at his sole discretion.

In that case I apologize. What a disingenuous statement on the website, then.

Re: Why SQLite does not use Git (2018)

#44

Post by [deleted] »

reaperducer wrote: post #34
Thaxll wrote: post #6

I think the explanation does not make any sense in 2023, if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. If you want to make your project more open to contribution you have to use what the rest of the industry is using. Edit: After reading some responses, I'm really surprised that sqlite does not accept contributions.

if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. That's pretty much the opposite of progress. At one time, 99.9% of developers used CP/M. At time, 99.9% of web was done in PHP. At one time, 99.9% of developers IBM XTs. At one time 99.9% of developers used SourceForce and SVN. Stuff changes. Monoculture is bad for the tech industry.

[deleted]

Re: Why SQLite does not use Git (2018)

#45

Post by devin »

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.

Re: Why SQLite does not use Git (2018)

#46

Post by blagie »

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 understand git.

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

Re: Why SQLite does not use Git (2018)

#47

Post by op00to »

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.

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?

Re: Why SQLite does not use Git (2018)

#48

Post by inferiorhuman »

reaperducer wrote: post #34
Thaxll wrote: post #6

I think the explanation does not make any sense in 2023, if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. If you want to make your project more open to contribution you have to use what the rest of the industry is using. Edit: After reading some responses, I'm really surprised that sqlite does not accept contributions.

if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. That's pretty much the opposite of progress. At one time, 99.9% of developers used CP/M. At time, 99.9% of web was done in PHP. At one time, 99.9% of developers IBM XTs. At one time 99.9% of developers used SourceForce and SVN. Stuff changes. Monoculture is bad for the tech industry.

On the one hand I'm inclined to agree about monoculture, on the other I've worked at a company where one employee dictated that we use bzr. Basically everything was an order of magnitude more difficult through minimal fault of bzr. None of the third party tooling worked with bzr, or if something did have bzr support it was dropped ages ago.

It's kind of the same situation with Github. The pain in moving away from it as they continue to slaughter the UX is still pretty great.

So yeah monoculture is bad but progress is painful.

Re: Why SQLite does not use Git (2018)

#49

Post by forrestthewoods »

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 for petabyte scale storage and terabyte scale partial clones, imho.

Git feels like an inferior technology that succeeded and now we’re mostly stuck with it. Maybe someday someone will create a proper Perforce competitor and we can all migrate to something that’s actually good.

Re: Why SQLite does not use Git (2018)

#50

Post by inferiorhuman »

mintplant wrote: post #25
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…

All the time. I would say at least 50% of my code browsing is done from my phone. I make heavy use of the mobile GitHub web interface for this (find-references support has been a godsend, search is still meh, I hate how they keep breaking basic find-in-page with SPA jank). Also Searchfox [0] when I need to comb through Firefox code (fast, excellent, no complaints—well, I guess blame on mobile could be better). Contex…

Yeah, I can't say enough bad things about the Github refresh. The whole thing feels like it was done by people who've never used git (or any SCM) before. It's not just the find-in-page, it's the navigating branches, text selection, keyboard navigation within a page, and general rendering performance that have taken a huge hit. And, of course, all the side effects of requiring javascript to render text.
Post reply on HN