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

331–340 of 454 posts

Re: Why SQLite does not use Git (2018)

#331

Post by Shorel »

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 Git + GitLab (to be feature equivalent) is a few GB and requires far more resources. Then which one does what it does well?

Now, there are a few things I don't like from Fossil, like the lack of a cherry-pick command. I have no intention of using Fossil over Git. I am just stating that criticism should be based on actual misfeatures and not on development "philosophies".

Re: Why SQLite does not use Git (2018)

#332

Post by IshKebab »

3cats-in-a-coat wrote: post #161
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…

The concept that you can isolate "one thing" and it's not in itself "a set of other things" is a very nasty myth in the world of programming. Everything is composite. Everything is a pipeline of commands. Made of things. The "job to do" is in the eye of the beholder, not absolute. The "single responsibility principle" is not applicable in reality. It's always a tradeoff of maintaining a balance of cohesion and modula…

They're not saying it doesn't encapsulate more than one thing. They're saying *at the abstraction level of "stuff you need to install and run" it is one thing.

Re: Why SQLite does not use Git (2018)

#333

Post by zrail »

sanderjd wrote: post #316
eru wrote: post #301

Earlier quoted context omitted.

OK, that makes sense. I think if you wanted to do this, it would probably be easiest to produce an artificial leaf that points to all the leaves you want to rebase.

Yes, and the original commenter's point is that git does not support this well, at the data model layer even. Because commits have exactly one parent commit, which is immutable, and because rebasing creates a new commit, rebasing an entire subtree with N nodes under it requires N operations, rather than just 1. Personally I think it's a pretty small price to pay for the advantage of the single-immutable-parent model,…

You're right that the tooling doesn't support it well but commits have more than one parent all the time, they're just called merge commits.

They can actually have as many parent branches as you please but conflicts get harder to deal with the more parents you have.[1]

[1]: https://www.freblogg.com/git-octopus-merge

Re: Why SQLite does not use Git (2018)

#334

Post by forrestthewoods »

happymellon wrote: post #283
genocidicbunny wrote: post #237

Earlier quoted context omitted.

Well, to be frank, git doesn't really handle binary files _at all_. I don't really consider treating binary files as opaque blobs of data as 'handling them'. It's more akin to throwing your hands up and saying 'fuck it, we'll treat it like the text stuff and whatever happens, happens.' Yes, over time git has gained some capability for handling binary data as delta patches, but it is so far away from anything even rem…

Because no one is driving a universal content aware diff, as far as I can tell. If you just want images then gitlab does a good enough job. https://gitlab.com/gitlab-org/gitlab-test/-/commit/2f63565e7... How would we represent video diffs? I don't deal with video so I'm not an expert, but there appears to be people complaining without suggesting solutions.

Not all version controlled files can be merged. That’s fine. Git sucks at working with large binary files. Perforce does not. Therefore all game devs use Perforce.

A theoretical Git2 could provide Perforce-tier support for large binary files. But, imho, this would likely require dropping the D in DVCS. I would gladly trade distributed for large binary file support. Without even a moment’s hesitation. Other people wouldn’t. But I wouldn’t call their use case “bad”.

Git is rubbish for my needs. It’s rubbish for a lot of needs. It’s ok at some things. Mercurial is much better at those things though.

Re: Why SQLite does not use Git (2018)

#335

Post by gumby »

booleandilemma wrote: post #293
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

Would their git provide file system access?

What a perfect comment: it’s impossible to conclusively declare it snark (unwelcome in HN comments) or a simple observation of fact (desired in HN comments).

Shakes head: oh Apple, can’t live with you, can’t live without you.

Re: Why SQLite does not use Git (2018)

#336

Post by IshKebab »

forrestthewoods wrote: post #218
lelanthran wrote: post #197

Earlier quoted context omitted.

> I’m so thankful that Rust is helping popularize the solo exe that “just works”. Wasn't it Go that did that? I mean, not only was Go doing that before Rust, but even currently there's maybe 100 Go-employed developers churning out code for every 1 Rust-employed developer.

Ehhh. You can compile a single exe with C or C++. I’ve personally come across far more Rust tools than Go. But I don’t really touch anything web related. YMMV.

It takes a ton of work to get a properly static C/C++ binary, whereas with Go (and to a slightly lesser extent Rust) it is the default.

In other words, it's possible with C/C++ but it's enough of a pain that few people actually bother.

Re: Why SQLite does not use Git (2018)

#337

Post by Shorel »

bane wrote: post #41
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.

I have no idea why Richard focuses on such things but: I'm old enough to remember when developers spent time making sure they could plow all of their build assets into a single binary distributable. It often had kind of a zest to it and when you dealt with software had directories full of stuff it looked both "corporate" and "sloppy". I've never quite gotten over the feeling that the piles of dynamically linked libra…

I agree with you so much.

Dynamic linking is the bane of backwards compatibility.

Now everything is containers, appimages, flatpacks, docker images and so on, and all they do is pack all the libraries a binary may need, in a more wasteful and inefficient format than static linking.

In that sense, we truly have the worst of both worlds.

Re: Why SQLite does not use Git (2018)

#338

Post by lloeki »

sanderjd wrote: post #316
eru wrote: post #301

Earlier quoted context omitted.

OK, that makes sense. I think if you wanted to do this, it would probably be easiest to produce an artificial leaf that points to all the leaves you want to rebase.

Yes, and the original commenter's point is that git does not support this well, at the data model layer even. Because commits have exactly one parent commit, which is immutable, and because rebasing creates a new commit, rebasing an entire subtree with N nodes under it requires N operations, rather than just 1. Personally I think it's a pretty small price to pay for the advantage of the single-immutable-parent model,…

> Because commits have exactly one parent commit

This is not true, merge commits are commits with > 1 parents (octopus merges are merely commits with > 2 parents)

But indeed since the parents commits are part of the computation of a commit's sha then by design changing the parents means changing the commit's sha, which is a very nice property to have.

That said, the model has what we said as a design consequence, but it's perfectly workable to have tooling that walks history and finds branching points and whatnot. Git does it all the time with existing porcelain commands, and I've done it in different contexts (e.g to produce diffs between tip and branching point, analysing which files have changed, and take action pertaining only to these file changes and their dependents) but the gist of it is the same.

It's merely a matter of such porcelain commands not being implemented and not being part of upstream git, so everyone either does it manually or invents their own tooling when they're sick of the pain point.

Re: Why SQLite does not use Git (2018)

#339

Post by yardie »

bombcar wrote: post #287
eru wrote: post #257

Earlier quoted context omitted.

I think mostly it will depend on what we will call the replacement to git. We might end up calling it 'git', too. Less weirdly: ethernet has been replaced a few times already, but they always just end up branding the replacement as a new version of 'ethernet'.

Many of those variations of ethernet remain compatible, 10g switches can often negotiate down to 10/100.

I’ve worked with many switches. I have not encountered a 10g switch that will negotiate to 10m. 100m is not automatic in most cases. These very old protocols are very different from modern 10g-100g. So much so that the transceivers may need to load a completely different firmware to even understand it.

Re: Why SQLite does not use Git (2018)

#340

Post by pravus »

tempay wrote: post #302
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…

> I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard. I agree that the model does but I’m not aware of any good way of using such a workflow with the CLI either. Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches?

> Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches?

This is the problem. You cannot rebase with a stacked PR flow. The correct way to do this is use the merge command as intended.

One of the most powerful features of git is the ability to understand a common history between multiple parties and everyone throws this away entirely with a rebase and causes non-stop conflicts. I simply do not understand the preference for it, especially in shared repos.

Do not use a rebase workflow with any work that is shared with others unless you are communicating regularly and understand how obliterating your commit history will change how git views what is changed between two repositories. Rebase only works well if you are in a leaf branch you control and even then I prefer a single squash merge back into upstream rather than multiple rebases if possible.

I can't even tell you how much of my life has been lost correcting merge conflicts caused by bad rebasing of my commits by others.

Post reply on HN