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

401–410 of 454 posts

Re: Why SQLite does not use Git (2018)

#401

Post by eternityforest »

rvba wrote: post #395
quietbritishjim wrote: post #228

Earlier quoted context omitted.

In fairness, the rate of change of any type of tool slows down over time as the problem domain becomes well understood. It's like the Joel on Software article (which annoyingly I can't find at the moment) about how software is always pretty much done by about version 4. His example was office software, especially Excel, and sure enough if you loaded Excel 4 today you'd see it does fundamentally all the main things. I…

Excel has recently introduced 4-5 VERY big changes: * javascript (arguably 'nobody' knows how to use it though, looking at the scarce resources) * Lambdas * Sharepoint integration, which is a type of shared notebook - and arguably this has ruined excel usability completely, since linking one file to another is basically unusable, what means were are back to the stone age, where people fucking copy paste things betwee…

I wonder why there's no true modern replacement for Excel that preserves the same versatility and ease of use for nontechnical users.

Every user could just have their own file, in which they could stash records(Or updates to other people's records), and you could have interfaces to view the data that look like a typical spreadsheet.

The data itself could live in an unsorted set of JSON objects with UUIDs, but the UI could be just as easy as Excel, you'd get tables that you could add or remove columns to and from, and put formulas in the fields, and query in some stripped down language with similar power to Excel.

And it could be 100% compatible, you would be free to put your data in the spreadsheet like the old fashioned way, sync with any cloud including SyncThing and no cloud at all, and data files could just be plain CSV you could version.

Re: Why SQLite does not use Git (2018)

#402

Post by estebank »

maccard wrote: post #318
jpc0 wrote: post #187

Earlier quoted context omitted.

And this is why you should stick to an 80 column limit. It's only a pain when you decide your codebase is fine with 120+ columns because "everyone has a widescreen monitor" except no they don't. What if I like vertical monitors, or want 5:4 etc.

Having to cater to the absolute lowest common denominator holds back progress. Why should I be forced to adapt your preferred workflow and limitations if I prefer to have a wide-screen monitor or another standard tool.

Without implying whether one position or the other is stronger, I want to point out that even when you're on a wide screen it's not uncommon to take advantage of that and have at least two screens side by side.

Re: Why SQLite does not use Git (2018)

#403

Post by Guvante »

tialaramex wrote: post #281
ozim wrote: post #221

Earlier quoted context omitted.

To paraphrase Bjarne Stroustrup, there are only two kinds of version control systems: the ones people complain about and the ones nobody uses.

It's very much a "glass half full" perspective, which gets tiresome from somebody like Bjarne who is very resistant to the idea that he's made mistakes. It excuses lots of bad mistakes because hey, if people really felt that way they wouldn't use C++ right? But of course increasingly they aren't using C++ because it sucks, which is why they were complaining. Unlike C++, Git has put considerable work into responding t…

I feel like you are being a bit unfair to Bjarne to to my knowledge isn't so much saying "we didn't make mistakes" as much as "we didn't make mistakes we should fix".

C++ is the juggernaut it is because it just works. Your antient C++ codebase doesn't need many changes to get up to date on a language level.

That doesn't mean it is painless to update toolchains but it does mean that the language isn't making that pain worse.

As part of maintaining this the bar for breaking old code isn't "we shouldn't have done that" or "we wouldn't have don't that" but something more like "almost all code using this is wrong anyway".

Most critiques of C++ do not raise to that level and so aren't fundamentally needing to be fixed.

Re: Why SQLite does not use Git (2018)

#404

Post by Guvante »

eru wrote: post #267
Guvante wrote: post #185

I think git gets a bad rep because no one can agree how to use it. GitHub PRs vs pushing a branch, rebase vs merge are just two examples of tools that do identical things in fundamentally different ways. And the problem is none of them are wrong. Rebasing minor commits simplifies unnecessary complexity in your history. Merging preserves what actually happened which can provide insight into why changes occurred. Of co…

It's important to distinguish between 'local disagreements' and 'social disagreements'. The former are things that don't affect anyone else. Eg your co-workers don't care if you your remotes 'origin' and 'upstream', or 'fork' and 'origin'. The latter are things you need to coordinate on with other people. Eg how you want your git history to look like in the end.

But my point is even the social disagreements are only social for your repo.

For the entirety of git they are local disagreements.

Re: Why SQLite does not use Git (2018)

#405

Post by tester756 »

eitland wrote: post #305
tester756 wrote: post #278

Earlier quoted context omitted.

git gets bad rep because its cli is a terrible mess if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess

> if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess Why then does every dev I am aware of who use Apple start by installing Homebrew? Also, you are talking about the same Apple that has a menu system that closes the menu if you click at a submenu? I mean, it breaks at least two reasonable assumptions: - clicking on a branch node would work on the branch l…

You may write 10 or even 100 examples

It's not that important, point stands regardless

Git's CLI UX is terrible.

Re: Why SQLite does not use Git (2018)

#406

Post by SQLite »

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 dispute this claim. The underlying artifact format for Fossil is compatible back to the beginning. There have been enhancements, but nothing that would break. And there have been no reports of breakage among the countless users on the Fossil Forum.

I suspect what the OP encountered was that he checked in some things using a newer version of Fossil that had enhanced capabilities. (For example, Fossil originally only use SHA1 hashes, but was enhanced to support both SHA1 or SHA3 after the SHAttered attack.) Then the OP tried to extract using an older Fossil that didn't understand the new feature and returned an error. I'm guessing at this, of course, but that seems like the most likely scenario.

I have never once made a backup of SQLite repo or the Fossil self-hosting repo, or any of the other 100+ Fossil repositories that I have at hand. I've cloned the repos to other machines as disaster protection. In fact, I have cron jobs running on machines all over the world that "sync" critical Fossil repositories (such as SQLite) once an hour or so. But I have never even once made a pure backup.

I did have the primary SQLite repo go corrupt on my once, years ago. Somehow, file descriptor 2 got closed. Then when the SQLite database that is the repository was opened, it opened on file descriptor 2. Then some bug in Fossil caused an assert() to fire which wrote on file descriptor 2, overwriting part of the database. I restored the repo from a clone, fixed the assertion fault in Fossil, and enhanced SQLite so that it refuses to use a file descriptor less than 3.

See also: https://fossil-scm.org/home/doc/trunk/www/selfcheck.wiki

Re: Why SQLite does not use Git (2018)

#407

Post by SQLite »

dilyevsky wrote: post #87
maxxk wrote: post #51

Earlier quoted context omitted.

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

It does do exactly that. If you visit https://sqlite.org/src/stat, the "Schema Version" line tells you exactly what version of the database schema that the repository is using. The SQLite repository uses the very latest Fossil schema, which you can see from the "stat" page has not changed in 8.5 years.

Re: Why SQLite does not use Git (2018)

#408

Post by zeroimpl »

JaDogg wrote: post #162
zeroimpl wrote: post #100

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.

IMHO, only problem with NIH is if it is not open. (Example create your own closed sourced - version control system, build tool, etc) Reinventing is how I learn, and there is no harm in that.

That’s true for personal projects, which is essentially the case here. If this was a business, not so much.

I was probably too harsh in my initial message, but when I read the article and see reasoning along the lines of “git lacks a good UI for X, I hear there may be 3rd-party solutions to this problem, but then that’s too many things to install, so I’d rather build a custom solution from scratch which does everything”, it reminds me of stuff I see at work ;)

Re: Why SQLite does not use Git (2018)

#409

Post by paulddraper »

quietbritishjim wrote: post #228
anon35 wrote: post #210

Made a list of all the revision control tools I've used over the decades, the year they were created, and the year I last used them: sccs 1973 2000 rcs 1982 2000 cvs 1990 2004 clearcase 1992 2004 perforce 1995 2011 subversion 2000 2015 mercurial 2005 2015 git 2005 present So, at least for me, they last around 15 years or so. But often time when I tell juinors that when they're my age, git will be distant a strange me…

In fairness, the rate of change of any type of tool slows down over time as the problem domain becomes well understood. It's like the Joel on Software article (which annoyingly I can't find at the moment) about how software is always pretty much done by about version 4. His example was office software, especially Excel, and sure enough if you loaded Excel 4 today you'd see it does fundamentally all the main things. I…

> software is always pretty much done by about version 4

IPv4 has entered the chat

Re: Why SQLite does not use Git (2018)

#410

Post by paulddraper »

mattbillenstein wrote: post #288
anon35 wrote: post #210

Made a list of all the revision control tools I've used over the decades, the year they were created, and the year I last used them: sccs 1973 2000 rcs 1982 2000 cvs 1990 2004 clearcase 1992 2004 perforce 1995 2011 subversion 2000 2015 mercurial 2005 2015 git 2005 present So, at least for me, they last around 15 years or so. But often time when I tell juinors that when they're my age, git will be distant a strange me…

Point could be made people don't really use git anymore - they use github as the primary interface. Branching, merging, review, etc.

I've never seen as the primary workflow.

It's handy, especially if you're using Git as a CMS or something like that.

Post reply on HN