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

81–90 of 454 posts

Re: Why SQLite does not use Git (2018)

#81

Post by gorjusborg »

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…

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.

Re: Why SQLite does not use Git (2018)

#82

Post by zaps »

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

In my experience, installing git on most Linux distros pulls in a bunch of perl dependencies

Re: Why SQLite does not use Git (2018)

#83

Post by hprotagonist »

LordShredda wrote: post #58
hprotagonist wrote: post #54

Earlier quoted context omitted.

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

Not an issue, if remote goes down you can always restore from backup

having been the guy who did that: i assure you, doing it is An Issue.

Re: Why SQLite does not use Git (2018)

#84

Post by docandrew »

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.

Wish I had more upvotes for this sentiment.

Re: Why SQLite does not use Git (2018)

#85

Post by lolinder »

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.

Slight tangent: it bugs me when people say "it goes against the Unix philosophy" as though The Unix Philosophy were some kind of religious text. Not everything should be a pluggable Unix executable, and Fossil making non-Unixy choices doesn't reflect poorly on it. They just chose a different philosophy.

Re: Why SQLite does not use Git (2018)

#86

Post by qbasic_forever »

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 idea exists or even why it's there. Stuff like sending email patches right from git: https://git-scm.com/docs/git-send-email

Re: Why SQLite does not use Git (2018)

#87

Post by dilyevsky »

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.

Afaik fossil just uses sqlite under the hood to store metadata. It would surprise me sqlite doesnt stash min and max required versions and refuse to work outside of those bounds

Re: Why SQLite does not use Git (2018)

#88

Post by forrestthewoods »

kstrauser wrote: post #62
hprotagonist wrote: post #54

Earlier quoted context omitted.

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

Or on a plane. It’s nice to have 100% of its functionality when you have 0% of your usual connectivity. Branches, commits, merges, all from the local file system? Yes, please. There’s a reason we moved off centralized VCS en masse.

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 numerous examples of this.

Re: Why SQLite does not use Git (2018)

#89

Post by qbasic_forever »

zaps wrote: post #82
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 In my experience, installing git on most Linux distros pulls in a bunch of perl dependencies

Git includes a web interface written as a perl CGI script, so yeah it has a lot more dependencies than people realize. It is most certainly not just a simple single binary to plop on a machine and call it good.

Re: Why SQLite does not use Git (2018)

#90

Post by thayne »

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…

I have had git corrupt repos. But usually not irreparably.
Post reply on HN