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

31–40 of 454 posts

Re: Why SQLite does not use Git (2018)

#31

Post by 8organicbits »

xrd wrote: post #27
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…

Well, I'm using git to manage my blog. I wrote an Android editor to edit on GitHub and then modified it to work on gitlab. There are lots of reasons but mostly it is because git is impossible to use on mobile, regardless of whether you are using GitHub or gitlab. Checking status is possible but barely anything beyond that. This write-up really resonated with me in other ways. I wrote a book for O'Reilly about GitHub…

I wonder how far you could get with the git client in termux. I got vim running at one point.

[1] https://termux.dev/

[2] https://packages.termux.dev/apt/termux-main/pool/main/g/git/

Re: Why SQLite does not use Git (2018)

#32

Post by JoeyBananas »

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…

There's no reason why that feature should not work on mobile. Certainly, it would work on mobile if it was designed/implemented better.

People access github from mobile all the time for the same reasons they access it from any other platform. I've certainly done it.

> I admit I haven't run into about half of these issues

These observations about git are not necessarily "issues." They're more like "value judgements about features." You either agree or you don't, there's nothing to encounter.

Re: Why SQLite does not use Git (2018)

#33

Post by Dylan16807 »

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…

My git seems to be mostly a single binary, and it's larger than fossil.

Re: Why SQLite does not use Git (2018)

#34

Post by reaperducer »

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.

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.

That's pretty much the opposite of progress.

At one time, 99.9% of developers used CP/M. At time, 99.9% of web was done in PHP. At one time, 99.9% of developers IBM XTs. At one time 99.9% of developers used SourceForce and SVN.

Stuff changes. Monoculture is bad for the tech industry.

Re: Why SQLite does not use Git (2018)

#35

Post by panzi »

queuebert wrote: post #30
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…

From an ABI perspective, there's not a huge difference, mostly just where the code resides on disk, all local or scattered across multiple inodes.

I think the point is that there is the option to have only git, which reduces the attack surface of only that tool, if you don't want/need anything else.

Re: Why SQLite does not use Git (2018)

#36

Post by jaimex2 »

I know about 5 git commands and have worked with gitflow and feature branch repos for years now.

I can't say I've ever had to think about anything or longed for a better system.

And yeah, I've also done the xkcd hack when things refuse to smash together.

Works for me.

As long as the Visual Code git blame extension keeps telling me line by line what ticket/issue was put when I'm happy.

Re: Why SQLite does not use Git (2018)

#37

Post by jayski »

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.

Re: Why SQLite does not use Git (2018)

#38

Post by avgjo »

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 never had GIT corrupt a repo in ten years of daily use - regardless of version.

Re: Why SQLite does not use Git (2018)

#39

Post by ninepoints »

qaq wrote: post #18
BuckRogers wrote: post #8

I’m sure git is less than ideal. I pretty much just know enough to do what I need to do with it. The only reason I want to use it is because it is the industry standard tool. Otherwise Hg, Perforce, have all had pretty compelling arguments put forward for their use. There’s so much technical churn in this industry, that any time I can use something that’s widely embraced I’m actually happy for that. Regardless of my…

I'd choose git over perforce any day.

I use git primarily, but if you work on a project that needs to version control data (images, textures, meshes, sky boxes, terrain, etc.), git, even with LFS, is such a terrible experience compared to Perforce.

Re: Why SQLite does not use Git (2018)

#40

Post by hotshiitake »

samspenc wrote: post #17
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 upvoted the post since I think it's a overall interesting technical discussion of git's downsides and some fossil upsides. But my response would be the same as what I argue in these React or other "popular-vs-other-frameworks" discussions that come: the alternatives may be better, faster, easier etc - BUT: - The popular solution has the larger ecosystem, and there are more existing plugins or modules you can plug-a…

Counterpoint - I get the same spiel from SEO marketing people trying to justify why every website in the org (including LoB web apps, intranet sites, etc.) needs to be a WordPress instance with 50 or so insecure plugins each. "But it's so popular!".
Post reply on HN