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

91–100 of 454 posts

Re: Why SQLite does not use Git (2018)

#91

Post by forrestthewoods »

gorjusborg wrote: post #81
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…

Binaries aren't source code. It sounds like you want a versioned file system, not source control. Git is a beautiful solution for its use case.

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. Its a god damn shame how much of our businesses use “stuff_final_final_05.psd” for “version control”.

Re: Why SQLite does not use Git (2018)

#93

Post by johannes1234321 »

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…

There are features which make life a lot better when you have them: A local search to explore, a way to stash the working state to try something out etc. and once you got those you have mostly a distributed VCS. True the flexibility of multiple remotes and tracking branches most users probably don't need, but it's quite nice for various things, and be it only a simple backup way.

On an aside: I always chuckle on the "distributed" VCS. Back in the days some people refered to CVS as a distributed VCS, comparing to RCS.

Re: Why SQLite does not use Git (2018)

#94

Post by forrestthewoods »

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.

Unrelated. Centralized version control systems are capable of offline mode.

Re: Why SQLite does not use Git (2018)

#95

Post by thayne »

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…

It is non-trivial to stand up a redundent, highly-available, and scalable git server. And if you throw in "with a good web interface", even moreso. But I doubt that is trivial to do with fossil either.

Re: Why SQLite does not use Git (2018)

#96

Post by resonious »

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…

Directories full of stuff is similar to websites with URL paths like "/site.php?page_id=18231238". Or even better when subdomains get involved and it looks like "secure3.action.domain.com/admin.php?page=123424". It technically works but is a bit ugly.

Also another web analogy might be dynamic linking being similar to microservices. People want to build and ship smaller components that can be swapped out independently. It works but does seem to make updating and testing fragile. You can test heavily at the boundaries but there's still kind of an "air gap" between the main app and the lib/microservice. If you want to be really sure there's no breakage, you have to test the whole thing, at which point you might as well just ship a monolith.

Re: Why SQLite does not use Git (2018)

#97

Post by saagarjha »

resonious wrote: post #96
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…

Directories full of stuff is similar to websites with URL paths like "/site.php?page_id=18231238". Or even better when subdomains get involved and it looks like "secure3.action.domain.com/admin.php?page=123424". It technically works but is a bit ugly. Also another web analogy might be dynamic linking being similar to microservices. People want to build and ship smaller components that can be swapped out independently…

Dynamic libraries make things nice to swap out for hacking or testing, though.

Re: Why SQLite does not use Git (2018)

#98

Post by thayne »

qbasic_forever wrote: post #86
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 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…

FWIW, that isn't actually part of the core git binary. Because unlike fossil, git is a collection of executables, not just one.

Re: Why SQLite does not use Git (2018)

#99

Post by gorjusborg »

forrestthewoods wrote: post #91
gorjusborg wrote: post #81

Earlier quoted context omitted.

Binaries aren't source code. It sounds like you want a versioned file system, not source control. Git is a beautiful solution for its use case.

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.

Re: Why SQLite does not use Git (2018)

#100

Post by zeroimpl »

Seems like a textbook example of NIH to me. By the time you understand git well enough to design a good replacement, you’re bound to be an expert and ought to appreciate more the design of git.

If you don’t like the lack of a good GUI or web application, you can just build one that works the way you want and still works with git.

Post reply on HN