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

381–390 of 454 posts

Re: Why SQLite does not use Git (2018)

#381

Post by kstrauser »

genocidicbunny wrote: post #194
kstrauser wrote: post #140

Earlier quoted context omitted.

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 periodicall…

It seems you're still largely talking about mostly text files. The parent you're replying to works in video games, where 99% of the data stored in VCS by volume (if it's even stored in VCS) is not text data. It is things like textures, audio files, processed geometry..etc. It is extremely easy to have one single texture take up more disk space than the entire source code for the game. > I can clone a remote repo, the…

The don’t use Git for it. Emacs is a crappy Photoshop replacement, but it’s great at it was actually built for. Git isn’t great for video game assets, but it’s great at what it was actually built for.

Use the right tool for the job. The parent poster is complaining that their employer picked the wrong tool for their job, then insisting that the tool sucks.

Re: Why SQLite does not use Git (2018)

#382

Post by bborud »

nwallin wrote: post #369
bborud wrote: post #284

Earlier quoted context omitted.

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 ne…

> What do you mean "which versions of which libraries"?

If you upgrade a shared library to fix a problem, how do you know that the application has been tested against the fixed version?

And no, your package manager won't know.

Congratulations on a) not having multiple installs of shared libraries on your system and b) for knowing which version you have. Knowing this isn't very common.

Re: Why SQLite does not use Git (2018)

#383

Post by flohofwoe »

backendanon wrote: post #370
flohofwoe wrote: post #254

Earlier quoted context omitted.

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

Azure is predominantly running Linux VMs, so that kinda reinforces my point. When targeting Linux, a UNIX shell is obviously the better choice.

Re: Why SQLite does not use Git (2018)

#384

Post by smazga »

jon-wood wrote: post #320
bonzini wrote: post #252

Earlier quoted context omitted.

Subversion is basically CVS done right. The problem is that CVS was a dead end that didn't scale to a distributed development model. Git goes back to the local RCS model and adds atomic commits to that model. That's how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turn…

I should at some point alias git checkout to throw a warning, git switch/restore are clearly a better choice, but unfortunately checkout is ingrained in muscle memory at this point.

I, personally, would find this very helpful if git did it by default. I learned git by searching for "how do I?" stuff. Now I know how to do things, so I don’t go looking. It's possible that there are new and improved workflows, but I'll never know because it already works for me, even if I do it "the hard way".

Re: Why SQLite does not use Git (2018)

#385

Post by blagie »

johannes1234321 wrote: post #103
blagie wrote: post #46

Most of these arguments are nonsense. "Standing up a git server is non-trivial." It's literally just "git init" and providing ssh access to the directory. Most of the other ones seem to suggest the author never learned git. git has a beautiful data model and a horrible user-space to poke at it. Writing a new user-space makes sense. This seems to poorly re-invent the data model, by virtue of not bothering to understan…

> and providing ssh access to the directory Well, doing that securely and somewhat aclainf isn't easy and file access permissions are a pain. If you remember to update the index regularly serving .git via HTTP is easy for read-only access, but all else is quite a bit more involved.

No. It's not. Set up git-shell instead of bash, and you're done. It's literally a one-liner.

There are similar one-liners for most other use-cases.

As a footnote, most environments I'm in, this is a non-issue since devs have ssh access to a common server somewhere. Once you get to the org size where this matters, it doesn't matter since you need Infrastructure with a capital I regardless.

Re: Why SQLite does not use Git (2018)

#386

Post by resurge »

GabrielTFS wrote: post #303
bonzini wrote: post #252

Earlier quoted context omitted.

Subversion is basically CVS done right. The problem is that CVS was a dead end that didn't scale to a distributed development model. Git goes back to the local RCS model and adds atomic commits to that model. That's how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turn…

> I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout. Welp, I guess there's me, but it does indeed seem like adoption of the new commands hasn't been very forthcoming - I guess that's what happens when "the old way still works just fine" - but personally I'd expect that more and more people will change to the new commands over time.

I just checked these commands out to update my git knowledge, but when I saw the following in the docs [1][2] I immediately marked these commands as not (yet) worth it to learn since the way these commands work might change.

  THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
So that might have something to do with it as well. Especially if there are stable commands that I already know that have the same functionality.

[1]: https://git-scm.com/docs/git-switch

[2]: https://git-scm.com/docs/git-restore

Re: Why SQLite does not use Git (2018)

#387

Post by bombcar »

yardie wrote: post #375
bombcar wrote: post #357

Earlier quoted context omitted.

100g may be too high, but my micro tick does fine: https://mikrotik.com/product/s_rj10 (I’ve not seen 100g over copper, but 10g is doable) I don’t know if it will go down to half duplex.

Ok. Most of my experience the switches will have 2 modes for each port: 1G/2.5G/10G/25G/100G or 10M/100M/1G/2.5G. This is typical for datacenter switches. Found this out when my trusty 10/100M USB dongle couldn't establish link. I needed to upgrade to a 1G USB3 dongle.

Now I want a datacenter switch with a gearshift for speeds, "high", "low" and "turbo" perhaps.

Re: Why SQLite does not use Git (2018)

#388

Post by blagie »

thayne wrote: post #95
blagie wrote: post #46

Most of these arguments are nonsense. "Standing up a git server is non-trivial." It's literally just "git init" and providing ssh access to the directory. Most of the other ones seem to suggest the author never learned git. git has a beautiful data model and a horrible user-space to poke at it. Writing a new user-space makes sense. This seems to poorly re-invent the data model, by virtue of not bothering to understan…

It is non-trivial to stand up a redundent, highly-available, and scalable git server. And if you throw in "with a good web interface", even moreso. But I doubt that is trivial to do with fossil either.

Redundant?

I think at some point, you missed the point of a DVCS.

Scalable?

When do you run into issues with git server scalability that an 80486 couldn't handle?

Highly-available?

At this point, just pay for !@#$ github. But it's a heck of a lot easier to do this in a DVCS than in fossil. Options:

- Set up two servers. Add a hook to push from one to the other whenever a change happens. If the main server goes down, swap to the backup, and bring up a new one as a backup.

- Store the git repo on a redundant, highly-available, scalable file system, and run a few git servers on the shared file system. Back in my day, we'd use AFS for this.

The nice thing about the data model is these solutions /work/. The basic git data model* won't be corrupted if multiple systems are writing to it more-or-less simultaneously. Absolute worst case is the tree splits and you've got a detached head somewhere, but no data is lost.

* I can't speak for some of the more advanced stuff (packing, compression, etc.), since I don't fully understand it; but it's possible to disable all of that.

Re: Why SQLite does not use Git (2018)

#390

Post by SQLite »

Shorel wrote: post #331
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 do prefer the "do one thing and do it well" approach. I prefer the "do what you do well" approach. If it's one thing, or many things, doesn't matter, as long as it's both efficient and correct. I mean, if Fossil fails at some of these things, then we can criticise it for its failings, but it appears it actually does the things correctly. The comparison with GitLab is quite enlightening. Fossil is a few MB, and Gi…

Use whatever VCS you like, but do please note that Fossil does have a "cherry-pick" command. See https://fossil-scm.org/home/help?cmd=cherry-pick for the documentation.

Earlier in it's history, Fossil didn't have a separate cherry-pick command, but rather just a --cherrypick option to the "merge" command. See https://fossil-scm.org/home/help?cmd=merge. Perhaps that is where you got the idea that Fossil did not cherry-pick.

Fossil has always been able to cherry-pick. Furthermore, Fossil actually keeps track of cherry-picks. Git does not - there is no space in the Git file format to track cherry-picks merges. As a result, Fossil is able to show cherry-picks on the timeline graph. It shows cherry-pick merges as dashed lines, as opposed to solid lines for regular merges. For example the "branch-3.42" branch (https://sqlite.org/src/timeline?r=branch-3.42) consists of nothing but cherry-picks of bug fixes that have been checked into trunk since the 3.42.0 release.

Post reply on HN