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

181–190 of 454 posts

Re: Why SQLite does not use Git (2018)

#181

Post by indeedmug »

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…

A lot of problem with Python packages is the fact that a lot of Python programs is not just Python. You have a significant amount of C++, Cython, and binaries (like Intel MKL) when it comes to scientific Python and machine learning. All of these tools have different build processes than pip so if you want to ship with them you end up bring the whole barn with you. A lot of these problems was fixed with python wheels, where they pack the binary in the package.

Personally, I haven't ran into a problem with Python packaging recently. I was running https://github.com/zyddnys/manga-image-translator (very cool project btw) and I didn't ran into any issues getting it to work locally on a Windows machine with Nvidia GPU.

Re: Why SQLite does not use Git (2018)

#182

Post by nmz »

maxxk wrote: post #51
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.

It is yes, they've even built a command for it "rebuild"[0]

> Reconstruct the named repository database from the core records. Run this command after updating the fossil executable in a way that changes the database schema.

[0]: https://fossil-scm.org/home/help?cmd=rebuild

Re: Why SQLite does not use Git (2018)

#183

Post by ogurechny »

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…

Then the author of that script is the one who deals with said complexity in that specific manner, either because of upstream inability to provide releases for every combination of operating system and hardware, or because some people are strictly focused on hard problems in their part of implementation, or something else.

A package manager with “well designed” packages still can't define what they do, invent program logic and behavior. Someone has to choose just the same, and can make good or bad decisions. For example, nothing prohibits a calculator application that depends on a full compile and build system for certain language (in run-time), or on Electron framework. In fact, it's totally possible to have such example programs. However, we can't automatically deduce whether packaging that for a different system is going to be problematic, and which are better alternatives.

Re: Why SQLite does not use Git (2018)

#184

Post by wodenokoto »

mindsuck wrote: post #171
ThinkBeat wrote: post #169

I am not a Git fan. The most perplexing to me is how huge companies spend 100.000s (1.000.000s??) of $$ to hack Git so that it will git with their needs. Like Google. One of the biggest issues seem to be the size of the repo, which takes days (?) to download and get started. Does Google contribute all their extra services / tools to make Git for work for then?

Google uses piper, not git

Isn't Android on git?

Re: Why SQLite does not use Git (2018)

#185

Post by Guvante »

I think git gets a bad rep because no one can agree how to use it.

GitHub PRs vs pushing a branch, rebase vs merge are just two examples of tools that do identical things in fundamentally different ways.

And the problem is none of them are wrong. Rebasing minor commits simplifies unnecessary complexity in your history. Merging preserves what actually happened which can provide insight into why changes occurred. Of course reverse merges are the worst but that is a can of worms...

When pushing to a branch you can never force push but you always force push a PR branch...

Hell sometimes the easiest things create unsolvable rifts. I know of the main repo as origin and fork for my fork. Some have learned that the main repo is upstream and origin is your fork.

Neither is necessarily wrong but good luck being clear when origin can refer to two locations with such extreme use cases.

Re: Why SQLite does not use Git (2018)

#186

Post by kaba0 »

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.

Unix’s philosophy is more of what you’d call ‘guidelines’, and is not universally applicable — not all problems can be decomposed nicely, and IPC just gives you a badly debuggable hodgepodge of added accidental complexity. It’s good for trivial tools like ls, cat, etc, but something more complex is likely better off as a monolith.

Re: Why SQLite does not use Git (2018)

#187

Post by jpc0 »

FpUser wrote: post #66
mintplant wrote: post #25

Earlier quoted context omitted.

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…

Can't imagine reading code on those tiny screens.

And this is why you should stick to an 80 column limit.

It's only a pain when you decide your codebase is fine with 120+ columns because "everyone has a widescreen monitor" except no they don't. What if I like vertical monitors, or want 5:4 etc.

Re: Why SQLite does not use Git (2018)

#188

Post by bsder »

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.

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

And this is why Microsoft is now in a monopoly position ... again ... simply by buying Github.

Programmers never learn.

Re: Why SQLite does not use Git (2018)

#189

Post by kaba0 »

MuffinCups wrote: post #120
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…

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…

> For that we have Docker these days

Or just a proper package manager, like nix.

Re: Why SQLite does not use Git (2018)

#190

Post by wodenokoto »

somenewaccount1 wrote: post #59

>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…

Everybody uses git as a cathedral style system by way of github/gitlab. So all things equal, it should scale just as well as a github project.
Post reply on HN