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

151–160 of 454 posts

Re: Why SQLite does not use Git (2018)

#151

Post by josephg »

ogurechny wrote: post #133
forrestthewoods wrote: post #53

Earlier quoted context omitted.

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.

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 install. What a mess! And why is the job of figuring out the right version of pytorch the job of an end user program? I don’t know if PyTorch is uniquely bad at this, but all this work is the job of a package manager with well designed packages.

It should be as easy as “cargo run” to run the program, no matter how many or how few dependencies there are. No matter what operating system I’m using. Even npm does a better job of this than python.

Re: Why SQLite does not use Git (2018)

#152

Post by Terr_ »

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…

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.

Re: Why SQLite does not use Git (2018)

#153

Post by School-Cotton »

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…

Why are you so often in situations where you want to browse code but don’t have access to a general-purpose computer?

Re: Why SQLite does not use Git (2018)

#154

Post by eesmith »

fritzo wrote: post #65
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…

That D in DVCS is much appreciated when my power goes off, my internet goes down, etc.

You might appreciate then how fossil improves on git. When that happens with fossil you can also still update the issue tracker and wiki, while many (most?) people depends on a centralized system like GitHub or GitLab for the latter.

Re: Why SQLite does not use Git (2018)

#155

Post by ckolkey »

avikalp wrote: post #128
qbasic_forever wrote: post #86

Earlier quoted context omitted.

Git actually is bundling a lot of stuff you probably don't realize. Run 'git instaweb' for example and it will spin up a local CGI server and perl CGI script to give a very simple web UI: https://git-scm.com/docs/git-instaweb Fossil isn't much different in core functionality here. There is a ton of email client integration and functionality in git too that most people who only use GitHub probably have absolutely no i…

I tried that (primarily because I didn't know about it and was excited), but it didn't work. It needs me to install "lighttpd" to work. And the steps to install that are not straightforward. I like that a lot of functionality is not bundled up in the git that I have already installed in my computer, but at the same time, I agree with the fact that adding these separate binaries is not easy as a user.

You can use different httpd backends - webrick if you have ruby, python, etc

Re: Why SQLite does not use Git (2018)

#156

Post by happymellon »

genocidicbunny wrote: post #118
gorjusborg wrote: post #99

Earlier quoted context omitted.

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.

The world wants you to use git for binary file versioning?

I have never encountered that. Binary files are generally kept in something like SharePoint, where it is SharePoint which is then hated by everyone.

It's interesting that regardless of the tool, everyone seems to hate it. Perhaps if all tools are wrong, you are trying to force a bad usecase?

Re: Why SQLite does not use Git (2018)

#157

Post by tony69 »

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.

Check out Nuitka

Re: Why SQLite does not use Git (2018)

#158

Post by JaDogg »

Woah, this sent me down a rabbit whole. Probably the best thing I saw for a long time.

Seems like you can use this and mirror in Git/GitHub as well. https://fossil-scm.org/home/doc/trunk/www/inout.wiki.

Builtin UI looks OK. (Usable and easy to navigate actually). But I was hoping the UI support commit as well. (I could not figure this out in UI). (so you don't have to mix command line and web interface to get things done)

I think if we can build a wrapper UI around fossil (which allows open, init, commit, sync?, sync-with-git, start-web-interface) (or even better add it to fossil itself). Then, this would be highly helpful to less-techy or non-devs that code (bio, math, data-science, etc) to maintain Jupyter notebooks,etc. Hmm, but perhaps a simple git-ui client can be used for that as well. (but you will loose the builtin wiki/tickets). And ability to work locally is useful as well (but then git can do that too). In any case I have seen less-techy people shy away from git (or version control in general).

I can see the potential in builtin wiki and tickets in same repo. One file to backup is also interesting.

Re: Why SQLite does not use Git (2018)

#159

Post by forrestthewoods »

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.

Kind of.

I think Git is a very clunky rock that results in people smashing their fingers and is custom designed for a very specific use case (Linux open source) that isn’t actually relevant to 99.99% of projects.

I think Git is a local minimum that people are ignorantly satisfied with. Everyone is using a mishappen rock and the popularity of this rock is inhibiting the creation of a proper hammer.

I could be wrong! But I am unfortunately forced to used Git due to its ubiquity even though it’s an extremely limited tool. Git does not spark my joy.

Mercurial is very similar to Git but incrementally better. In a different world we’d all use MercurialHub. I wouldn’t be fully happy with Mercurial either. But the point is that Git’s ubiquity has to do with ecosystem factors beyond its intrinsic capabilities and design.

Git is a mediocre hammer, at absolute best. I want a great hammer. Users incorrectly think Git is a great hammer which is making it difficult for an actually great hammer to be built.

Almost all HN users will disagree with me. They’re quite happy with Git and think it’s a great hammer. I think they’re all wrong. But maybe it is me who is wrong! :)

Re: Why SQLite does not use Git (2018)

#160

Post by dan-robertson »

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…

Plenty of tech companies have massive monorepos which large numbers of people contribute to. I don’t know how easy it is for one person to see another’s branch though. So: maybe it can scale, at least somewhat, with a more centralised system.
Post reply on HN