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

131–140 of 454 posts

Re: Why SQLite does not use Git (2018)

#131

Post by KerrAvon »

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…

Counterpoint: Lots of people actually use and like the D aspect. It’s one of the best things about Git!

Local git repos can be shallow or partial clones if you insist on it. You say elsewhere that a VCS should support an offline mode instead, but if that’s not a copy of the repository, how is it in any way equivalent and what exactly is the difference?

I’ve never understood why people like Perforce; I’ve assumed it’s some kind of weird nostalgia for mainframe user interfaces. I understand that it handles some kinds of large assets better than Git, but Perforce is so bad at everything else.

Re: Why SQLite does not use Git (2018)

#132

Post by avikalp »

backendanon wrote: post #123
qbasic_forever wrote: post #101

Earlier quoted context omitted.

Yes, which is why git is a pain in the butt to install and you have to rely on your OS packages (which includes all the kitchen sink stuff) or a GUI installer with all the necessary dependencies vs. Fossil which is just download executable and done.

git...is difficult to install? What's difficult about apt-get install git?

These is exactly what my first thought was! Installing open-ssh and git is kind of my first activity on a new computer. But I believe they are talking about setting up a git server. The thing that we rely on GitHub/GitLab/Bitbucket for. Richard counts them as an added dependency.

(I mean, he is not wrong in being worried about that. You are basically giving your all your code to a company. Which does not matter for open-source projects like SQLite, but it does for many private projects with code as their primary IP)

Re: Why SQLite does not use Git (2018)

#133

Post by ogurechny »

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.

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 blocks and their relative importance), when they might not be available, and which releases break which compatibility options, or they say “it builds for me with default settings, everything else is not my problem”.

Re: Why SQLite does not use Git (2018)

#134

Post by KerrAvon »

hprotagonist wrote: post #83
LordShredda wrote: post #58

Earlier quoted context omitted.

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.

I was once responsible for doing this with a Perforce server. Only time in my career a VCS has lost data. This was decades ago now and the data loss might have been due to hardware; I cannot definitively blame Perforce, but man was it shitty to deal with at the time. We migrated to Subversion and never had another issue.

Re: Why SQLite does not use Git (2018)

#135

Post by eesmith »

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.

> 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 'rmdir' exists. It does one thing, well - remove an empty directory. It's been around since the first release of Unix.

However, I use "rm -rf" because it's easier to use a more powerful tool which handles empty directory removal as a special case.

You can also change your viewpoint and say that Fossil does do one thing well: it's a distributed project control system. That's a new category I just made up, to highlight just how subjective "one thing" is.

Re: Why SQLite does not use Git (2018)

#136

Post by anotherhue »

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…

Wouldn't KSM help with that? If the security concerns aren't a factor.

Re: Why SQLite does not use Git (2018)

#137

Post by KerrAvon »

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…

Ah, this is why you have a bad attitude about the “D” part of “DVCS”, right? The workflow for art is “I need to lock that graphics asset so that no one else edits it while I’m editing it,” which you can’t do with a DVCS. Disallowing exclusive edits is generally what most programming teams want; otherwise it’s a daily occurrence to try to get someone to unlock a file they locked for editing and forgot about.

Re: Why SQLite does not use Git (2018)

#138

Post by tayo42 »

avikalp wrote: post #132
backendanon wrote: post #123

Earlier quoted context omitted.

git...is difficult to install? What's difficult about apt-get install git?

These is exactly what my first thought was! Installing open-ssh and git is kind of my first activity on a new computer. But I believe they are talking about setting up a git server. The thing that we rely on GitHub/GitLab/Bitbucket for. Richard counts them as an added dependency. (I mean, he is not wrong in being worried about that. You are basically giving your all your code to a company. Which does not matter for o…

Git server is just setting up ssh keys and a directory. The code base viewer runs with apache which is also pretty simple to get all set up

Re: Why SQLite does not use Git (2018)

#139

Post by never_inline »

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…

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

Fork uses CoW, right?

Re: Why SQLite does not use Git (2018)

#140

Post by kstrauser »

forrestthewoods wrote: post #88
kstrauser wrote: post #62

Earlier quoted context omitted.

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…

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 periodically pull in upstream changes, merge them into my working copy, then push those changes out to my worker instances. I might SSH into one of those servers, fix something specific to it, push the changes out to the other local servers so that they're all synced, and repeat for weeks and months on end.

And because each of those repos are equally "official", all branching and merging operations are equally easy on each one of the peer machines. Although it's conceptually possible that it could be just as easy on a VCS that doesn't work with full clones, I've never seen it.

Post reply on HN