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

191–200 of 454 posts

Re: Why SQLite does not use Git (2018)

#191

Post by nmz »

eska wrote: post #43
upon_drumhead wrote: post #19

Earlier quoted context omitted.

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.

I wouldn't classify it as disingenous, legalities are difficult, especially when you can't afford github's infrastructure and lawyers to write you up a CLA and a userbase that is not even aware of the TOS they're agreeing to. It's the only way to go.

Re: Why SQLite does not use Git (2018)

#192

Post by genocidicbunny »

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 …

I would love to see a DVCS that can effectively handle repos of the size I've seen. How well does DVCS work when your repo shallow copy is about 10TB?

Re: Why SQLite does not use Git (2018)

#193

Post by usrusr »

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.

Exceptional things rarely happen without some outlier conviction involved. Most things happening due to outlier convictions are just that, follies that lead nowhere. But when the stars align and there's both great ability involved and a genuine gap to fill that would have remained undiscovered workout the outlier conviction, something like SQLite happens.

Re: Why SQLite does not use Git (2018)

#194

Post by genocidicbunny »

kstrauser wrote: post #140
forrestthewoods wrote: post #88

Earlier quoted context omitted.

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…

That's an interesting, and wrong, definition of "wrong". Git, Mercurial, and the like make every full copy of the repo equal. By convention, we often use central repos like GitHub, and commands like "git fetch" and "git push" as fast ways to sync their contents. We don't have to, though. I can clone a remote repo, then work independently for months. I do this all the time with the Mastodon server I run. I periodicall…

It seems you're still largely talking about mostly text files. The parent you're replying to works in video games, where 99% of the data stored in VCS by volume (if it's even stored in VCS) is not text data. It is things like textures, audio files, processed geometry..etc. It is extremely easy to have one single texture take up more disk space than the entire source code for the game.

> I can clone a remote repo, then work independently for months.

If you're working with more than 0 other people in video games, good frakking luck doing this. If you're working on a large enough game, you're also going to need potentially multiple TB of storage just to have a full shallow copy of the repo (with just the latest copies.) I have worked at a studio where a full deep clone of the repo for just one game was well over 100TB. Let's see you load that up on your laptop.

Re: Why SQLite does not use Git (2018)

#195

Post by alpaca128 »

josephg wrote: post #151
ogurechny wrote: post #133

Earlier quoted context omitted.

The choice is actually between dealing with complexity and shifting responsibility for that to someone else. The tools themselves (e.g. virtual environments) can be used for both. Either people responsible for packaging (authors, distribution maintainers, etc.) have some vague or precise understanding of how their code is used, on which systems, what are its dependencies (not mere names and versions, but functional b…

> Either people responsible for packaging have some vague or precise understanding of how their code is used, on which systems, what are its dependencies But with python it’s a total mess. I’ve been using automatic1111 lately to generate stable diffusion images. The tool maintains multiple multi-hundred line script files for each OS which try to guess the correct version of all the dependencies to download and instal…

I remember having to modify one of those dependency scripts to get it running at all on my laptop. In the end I had more luck with Easy Diffusion. Not sure why, but it also generated better images with the same models out of the box.

Re: Why SQLite does not use Git (2018)

#196

Post by [deleted] »

Terr_ wrote: post #152
bane wrote: post #41

Earlier quoted context omitted.

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…

Somehow this makes me think of games Back In The Day where you could simply replace your crosshair by editing a bitmap file, versus now where everything's so much more locked-down behind proprietary container formats and baked-in checksums, etc.

[deleted]

Re: Why SQLite does not use Git (2018)

#197

Post by lelanthran »

forrestthewoods wrote: post #53
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’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.

> I’m so thankful that Rust is helping popularize the solo exe that “just works”.

Wasn't it Go that did that? I mean, not only was Go doing that before Rust, but even currently there's maybe 100 Go-employed developers churning out code for every 1 Rust-employed developer.

Re: Why SQLite does not use Git (2018)

#198

Post by willdr »

NikkiA wrote: post #109
willdr wrote: post #78

Earlier quoted context omitted.

But on a developer machine this doesn't matter does it?

Actually it does, because with the windows git it includes it's own copy of ssh and bash, both of which will clash and fight with msys and/or other ssh installs - including the copy of ssh that microsoft themselves tuck away in \windows\system32 it's quite 'normal' for git-for-windows' ssh-agent to completely disable ssh-agent from working properly system-wide because it ends up pointing things at the wrong ssh-agent…

But a developer isn't using Windows.

Re: Why SQLite does not use Git (2018)

#199

Post by casey2 »

fbdab103 wrote: post #104
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.

Let's not forget how long it even took for there to be a reasonable Windows build of git. Git implicitly relied on significant amounts of Linux tooling which required bringing over an entire Mingw environment.

>lets not forget I'd gladly take a FOSS Visual Studio on Linux. Heck, I won't even hold a grudge if it's under 60MB. Promise.

Re: Why SQLite does not use Git (2018)

#200

Post by herewulf »

eesmith wrote: post #135
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.

> it goes against the Unix philosophy of do one thing and do it well For me, Perl shows just how restricted that viewpoint was. After I learned Perl, I stopped caring about tr, and sed, and many of the other "one thing well" command-line tools. And I've no desire to swap out and modify the 's//' component of perl. Perl does "one thing" - interpret Perl programs - even though it also replaces many things. I know 'rmdi…

I like `rmdir` because I don't have to check if a directory that I think is empty is actually empty with `ls -la` before removing it. This happens a lot with moving stuff out of directories (sometimes to different destinations).
Post reply on HN