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

361–370 of 454 posts

Re: Why SQLite does not use Git (2018)

#361

Post by blitz_skull »

yjftsjthsd-h wrote: post #124
blitz_skull wrote: post #92

[flagged]

> It’s easy one of the most powerful, flexible, Probably, yeah. > and if you take the time to learn it, SIMPLE models for version control. ... And there it all falls apart. In practice, git requires a massive amount of learning to use competently, to the point that using something else just to avoid the learning curve is fairly reasonable.

I forced myself to learn it as a junior dev. Was it tough? Sure. But my point is that if it's too daunting and frustrating—software development holds nothing but pain for you.

Re: Why SQLite does not use Git (2018)

#362

Post by blitz_skull »

jmull wrote: post #107
blitz_skull wrote: post #92

[flagged]

You think the lead developer of sqlite may not be cut out for software development? Also, what does 2023 have to do with it?

git has been around since 2005. It's ubiquitous. And yes, I think it's a short-sighted and not-great decision to build your own version control system. Whether you're the lead developer of the unix kernel or just some guy writing your own scripts, it's not a good decision. Your title doesn't have much to do with that.

Re: Why SQLite does not use Git (2018)

#363

Post by tzs »

IshKebab wrote: post #342
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.

The Unix philosophy was a very rough guideline from the 70s, not a divine commandment that must be followed unwaveringly. There are a gazillion examples of excellent pieces of software that don't do "one thing" that can be piped as unstructured text into another program. Imagine editing a spreadsheet like `cat foo.xls | select-cell B3 | replace '=B2+1' > foo.xls`. Laughable. But how many people decry Excel for "not m…

> Imagine editing a spreadsheet like `cat foo.xls | select-cell B3 | replace '=B2+1' > foo.xls`.

It would be even more cumbersome than that. After that command you'd have to restore foo.xls from a backup, and then do the edit again this time remembering that the "> foo.xls" executes before the pipe executes. :-)

I wonder if anyone has written something to make pipes like that work? E.g., write two programs, "replace" and "with" that could be used like this:

  replace foo.xls | ... | with foo.xls
What "replace [file]" would do is set a write lock on the file, copy the file to stdout, then release the lock.

What "with [file]" would do is copy stdin to the file, after obtaining a write lock on the file. I think most shells would start the components of a pipe in order so "replace" should be able to set its lock before "with" tries to get a lock, but to be safe "with" could be written to buffer incoming data and only start checking the lock after it has received a significant amount or seen an EOF on stdin. Or "replace" and "with" could coordinate using some out-of-band method.

Re: Why SQLite does not use Git (2018)

#364

Post by emmanueloga_ »

bobmaxup wrote: post #259
jasonjayr wrote: post #26

Earlier quoted context omitted.

> git-erase-working-treeshould be used when you want to cautiously erase the current working tree of an upstream root and the config, and want to quiltimport to a active GUI. sounds useful!

https://git.savannah.nongnu.org/cgit/quilt.git/tree/quilt

https://users.suse.com/~agruen/quilt.pdf

Re: Why SQLite does not use Git (2018)

#365

Post by seba_dos1 »

kps wrote: post #351
seba_dos1 wrote: post #282

Earlier quoted context omitted.

> (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) Not sure if you realize, but a commit is a state of all files in the repository, not a patch. Patches are calculated for you at display time (and can be calculated against any other commit, not just a parent). Sounds like you may be confused because of trying to apply a wrong mental model of how the rep…

> Not sure if you realize, but a commit is a state of all files in the repository, not a patch. I think that's a core problem. It's not just that git calculates a patch to show you, it's that — in every git-using project I've seen — a developer writes a patch, and writes a commit message describing that patch . It's not just github. And then developers make the incorrect assumption that git's later presentation of th…

The developer never writes a patch when using git. The developer creates a new repository state, links it to a parent state (or multiple parent states) and describes the difference between these states in the commit message. A patch form is just a handy way to visualize these changes.

You can dump commits into patches and then apply them onto different repositories, but in order to do that you still have to convert such patch into a new repository state first.

Many people "learn" git by learning which commands to use to do some things and in turn don't understand what's going on at all. It's like learning how to write a letter by reading Word's manual.

Re: Why SQLite does not use Git (2018)

#366

Post by backendanon »

kaba0 wrote: post #180
backendanon wrote: post #123

Earlier quoted context omitted.

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

For what it’s worth, on windows without wsl you literally have to bring half of a whole unix with you to run git.

I'm a Linux person but often at work due to decades of Gates's effective brainwashing I almost always have to use windows on the desktop. IBM was the only exception. That said, on windows, all I do is get this https://git-scm.com/download/win run the installer and yes it installs stuff but it's literally all automatic. So it's easy on Windows and on Linux, Mac I don't know, I don't do Apple products.

Re: Why SQLite does not use Git (2018)

#367

Post by iFreilicht »

brigandish wrote: post #219
School-Cotton wrote: post #153

Earlier quoted context omitted.

Why are you so often in situations where you want to browse code but don’t have access to a general-purpose computer?

I do it when I want to separate out the thinking/understanding from the doing. I might want to mull over how to do something instead of jumping straight into coding, and I find train journeys an excellent opportunity for this. Or sometimes I want to assess dependencies, perhaps I want to choose a library for doing X, I can sit and read through them on my phone and at least get a feel for them and whittle the list dow…

Oh that's a good way to put it! I do this as well, especially on commutes or on walks, but sometimes on the couch as well; I have an idea and think about it actively, but to continue my thought process, I have to look at some code, so I open it on the phone.

It always felt weird to get my laptop and look on the "big" screen in those situations, and maybe it's because I just want to think, not to code.

Re: Why SQLite does not use Git (2018)

#368

Post by backendanon »

mkl wrote: post #212
alophawen wrote: post #207

Earlier quoted context omitted.

Not really. https://gitforwindows.org/

From that page: "Git for Windows provides a BASH emulation used to run Git from the command line. *NIX users should feel right at home, as the BASH emulation behaves just like the "git" command in LINUX and UNIX environments."

That's correct, it works automatically and is great to fix windows (when I have to work on windows) so it has some functionality but even if all I used out of that was git, it's easy. Is it all one exe? No. Does it need to be? No.

Re: Why SQLite does not use Git (2018)

#369

Post by nwallin »

bborud wrote: post #284
beebmam wrote: post #55

Earlier quoted context omitted.

If you're using TLS/crypto in an app, it's scary to statically bundle those libraries.

In my practical experience the set of things that can go wrong if you link apps dynamically is much larger than the problems that arise when they are statically linked. For one, it is more complicate to keep track of which of the many shared libraries on a typical system are used by which application. It is common that the same library occurs multiple times in different versions, built by different people/organizatio…

> For one, it is more complicate to keep track of which of the many shared libraries on a typical system are used by which application. It is common that the same library occurs multiple times in different versions, built by different people/organizations and residing in different directories.

That's not common at all, man. I strongly recommend you don't do that.

> Quick, without looking: which TLS library do your network exposed subsystems use, which directories are they in and where did you install them from.

Openssl 3.x.y. It's /usr/lib64/openssl.so or similar. They are installed from my distro's repository.

> When you do go to look: did you find what you expected?

Yes. Openssl 3.1.1-r2. The OpenSSL binaries are actually named /usr/lib64/libssl.so and /usr/lib64/libcrypto.so. Upstream version is 3.1.2. There have been two low priority CVEs since 3.1.1 (never change openssl...) and my distro has backported the fixes for both of them into 3.1.1-r2.

> Do you know which versions of which libraries work with which binaries?

What do you mean "which versions of which libraries"? There's only one version of each library. If the package manager needs to keep an old version of a library around, it gives a loud warning about it so I can either fix the problem or ignore it at my own peril.

Those two .so files (libssl.so and libcrypto.so) as used by postfix, dovecot, and nginx. They are also linked by opendkim, spamassassin and cyrus-sasl, but those don't have open ports on the internet, so they don't really count. OpenSSH can optionally link to openssl; as it happens, my openssh does not link against a crypto library, openssl or otherwise. It just uses openssh's built in crypto schemes.

> Do you trust the information your package manager has about version requirements?

Yes.

> Does it even have that information?

... wat..? Of course it does?

> I've been in the situation where someone inadvertently updated a library in production and everything came crashing down. Not only did it take down the site, but it took a while to figure out what happened. Both because the person who did it wasn't aware of what they'd done. And the problem didn't manifest itself in a way that made the root cause obvious.

I've been in the situation where a security guard at my last job inadvertently discharged his service revolver into a Windows machine, and it crashed. That doesn't mean I stopped using Windows. (I mean, I did stop using Windows...)

That's genuinely just not a problem that I've had. Not since 2004 and all the C++ programs on my computer broke because I force upgraded from GCC-3.3 to GCC-3.4 and the ABI changed. Or that time in 2009 where I installed a 0.x version of Pulseaudio on my gaming machine. Or that time I replaced OpenSSL with LibreSSL on my personal computer. If your server takes a shit because somebody was fucking around doing stupid shit on prod, and you do root cause analysis and come up with a reason that it broke other than, "employee was fucking around and doing stupid shit on prod" and the recommendation is something other than "don't fuck around and do stupid shit on prod" I don't know what to tell you. Dynamic linking isn't going to stop a sufficiently determined idiot from bringing down your server. Neither will static linking.

Re: Why SQLite does not use Git (2018)

#370

Post by backendanon »

flohofwoe wrote: post #254
lolive wrote: post #220

Earlier quoted context omitted.

GitBash, AutoHotkey, Notepad++, 7zip and PowerToys are the basic installs I do on any Windows I am given. Any dev opening a CMD is suspect, to me.

Except that pretty much all cmdline scripts on Windows are either .bat or .ps scripts, which in turn have tons of Window-isms built into them. If you are using bash on Windows that just tells me that the software you build probably won't be integrated all that well with Windows ;) (git and other "UNIX-y" tools work mostly fine on cmd.exe btw)

"If you are using bash on Windows that just tells me that the software you build probably won't be integrated all that well with Windows ;)"

Microsoft (you may have heard of them) seems to disagree: https://learn.microsoft.com/en-us/cli/azure/azure-cli-learn-...

Post reply on HN