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

441–450 of 454 posts

Re: Why SQLite does not use Git (2018)

#441

Post by throwawaymobule »

csydas wrote: post #266
resonious wrote: post #96

Earlier quoted context omitted.

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…

>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. OOC, why does this stand out for you? Just to explain my curiosity, I've worked on Mac since I was a kid starting with System 6 and then going to OS X when it came out…

Bit of a tangent, but those .app 'files' are directories. I wish other OSs supported something like that.

Those APE executables (e.g. redbean) are the closest I've seen that work widely.

Re: Why SQLite does not use Git (2018)

#442

Post by jpc0 »

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.

> Having to cater to the absolute lowest common denominator holds back progress.

Market decided wide screen is better on pc, you blindly followed. Market decided that isn't the case on any mobile platform which in case you missed it vastly out numbers pc.

There was never an argument about whether wide screen is better or not, only that larger column counts make it harder to read your code.

Using obscure single letter variable names also make your code harder to read, is using decent variable names catering to thw lowest common denominator as well, is that a bad thing? Are we holding back progress because we use descriptive names for things?

Make your case about column width, there are valid arguments for longer widths. "Because wide screen is better" isn't one I will accept, last I check no other written media prefers being printed in landscape.

Re: Why SQLite does not use Git (2018)

#443

Post by hprotagonist »

KerrAvon wrote: post #134
hprotagonist wrote: post #83

Earlier quoted context omitted.

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.

watching inodes fail before my eyes was … not an experience i’d care to repeat

Re: Why SQLite does not use Git (2018)

#444

Post by xelxebar »

pkulak wrote: post #150
kasperset wrote: post #106

I saw this video few days ago which describes some of the alternative to Git and of course Fossil is one of them. I have used Fossil in some projects and found to be ok. I found Pijul https://pijul.org/ described in this talk to be very interesting. It was discussed on HN before. Source: https://www.youtube.com/watch?v=M4KktA_jbOE

Pijul has always fascinated me. It’s like the holy grail of version control. But for my personal projects, I develop in a straight line anyway, and I’m not in control of what’s used at work, so I’ve never really used it.

Check out https://github.com/martinvonz/jj/. It's highly inspired by Pijul, among VCSes, and uses a git backing store, so you can use it personally and (mostly) seamlessly interact with any git-only team.

Re: Why SQLite does not use Git (2018)

#445

Post by dilyevsky »

SQLite wrote: post #407
dilyevsky wrote: post #87

Earlier quoted context omitted.

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.

Thanks for comment. Yeah I figured parent comment was suspect

Re: Why SQLite does not use Git (2018)

#446

Post by Git-Master »

cryptonector wrote: post #418
Git-Master wrote: post #304

Earlier quoted context omitted.

> At Sun we had a strict linear history mandate Out of curiosity: Was this also with TeamWare/SCCS? > If you care about history, what you really want is to see what's changed over time, and that is always linear. At time t_n you have some commit, and at t_n+1 you have some other commit, and so on. Depends on what the history should represent or what you care about specifically, or optimize for. What landed in the int…

Did you join HN just to comment on my comment? That's funny.

Yes. Usually, I come here only for the linked articles and read some discussions, but don't write. But this was too interesting to not comment, so I had to create an account.

Re: Why SQLite does not use Git (2018)

#447

Post by Git-Master »

cryptonector wrote: post #417
Git-Master wrote: post #304

Earlier quoted context omitted.

> At Sun we had a strict linear history mandate Out of curiosity: Was this also with TeamWare/SCCS? > If you care about history, what you really want is to see what's changed over time, and that is always linear. At time t_n you have some commit, and at t_n+1 you have some other commit, and so on. Depends on what the history should represent or what you care about specifically, or optimize for. What landed in the int…

> Out of curiosity: Was this also with TeamWare/SCCS? Yes. It was quite primitive by comparison to git, but it worked. > > If you care about history, what you really want is to see what's changed over time, and that is always linear. At time t_n you have some commit, and at t_n+1 you have some other commit, and so on. > Depends on what the history should represent or what you care about specifically, or optimize for.…

Thanks a lot, that was quite interesting! Always interested in different ways of doing things and the reasons behind them.

Just to add to your last point regarding hiding history details: that seems to be fossils way of doing it[1][2], if needed/wanted. The history is still in the repo, but the presentation can be cleaned up. (But this part of fossil I only know from the documentation, I have not used it that much.)

1. https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#...

2. https://fossil-scm.org/home/help?cmd=amend

Re: Why SQLite does not use Git (2018)

#448

Post by cryptonector »

Git-Master wrote: post #446
cryptonector wrote: post #418

Earlier quoted context omitted.

Did you join HN just to comment on my comment? That's funny.

Yes. Usually, I come here only for the linked articles and read some discussions, but don't write. But this was too interesting to not comment, so I had to create an account.

I'll take that as a badge of honor.

Re: Why SQLite does not use Git (2018)

#449

Post by cryptonector »

Git-Master wrote: post #447
cryptonector wrote: post #417

Earlier quoted context omitted.

> Out of curiosity: Was this also with TeamWare/SCCS? Yes. It was quite primitive by comparison to git, but it worked. > > If you care about history, what you really want is to see what's changed over time, and that is always linear. At time t_n you have some commit, and at t_n+1 you have some other commit, and so on. > Depends on what the history should represent or what you care about specifically, or optimize for.…

Thanks a lot, that was quite interesting! Always interested in different ways of doing things and the reasons behind them. Just to add to your last point regarding hiding history details: that seems to be fossils way of doing it[1][2], if needed/wanted. The history is still in the repo, but the presentation can be cleaned up. (But this part of fossil I only know from the documentation, I have not used it that much.)…

Quoting from #1:

> Git puts a lot of emphasis on maintaining a "clean" check-in history. Extraneous and experimental branches by individual developers often never make it into the main repository. Branches may be rebased before being pushed to make it appear as if development had been linear, or "squashed" to make it appear that multiple commits were made as a single commit. There are other history rewriting mechanisms in Git as well. Git strives to record what the development of a project should have looked like had there been no mistakes.

Right, exactly, because the mistakes often aren't interesting. Where mistakes made in development were interesting, then you should write up the interesting details in you code or commit commentary or other documentation.

> Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors, dead-ends, experimental branches, and so forth. One might argue that this makes the history of a Fossil project "messy," but another point of view is that this makes the history "accurate." In actual practice, the superior reporting tools available in Fossil mean that this incidental mess is not a factor.

But that's just so much noise! Some devs will make much more noise than others. Devs who commit often, for example, will make more noise. Noise noise noise. If I'm spelunking through the history I don't want noise -- I want signal. Even if I'm looking through history to find out who is a better developer it may not be helpful because some devs will commit more often.

I mean, why not just record your interactive sessions and then play them back when you want to look at the history? Where would the madness stop?

IMO the madness stops at the upstream, where only linear history should exist.

And again, if I want to look at a project's internal history I can look at their archived clone of the upstream. Even in project "gates" (as we called them at Sun) we kept linear history (some projects had very long history, like ZFS and SMF for example). Very few people looked through archived gates -- I did, from time to time, especially the old SEAM (Kerberized NFS) gates from 1999-2000, but not only. Some archives did get lost -- especially really old ones, the ones that matter more to historians than to current developers, so that sort of loss is a problem, but not one that threatens the ability to do work.

Re: Why SQLite does not use Git (2018)

#450

Post by westurner »

westurner wrote: post #111
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.

Securing the software supply chain for software updaters and VCS systems means PKI and/or key distribution, cryptographic hashes and signatures, file manifests with per-archive-file checksums, and DAC extended filesystem attributes for installed files; Ironically, there's more to it than just `curl`'ing a binary into place and not remembering to update it. And that is why package managers.

And sigstore; for centralized software artifact (package,) hashes: https://sigstore.dev/
Post reply on HN