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

431–440 of 454 posts

Re: Why SQLite does not use Git (2018)

#431

Post by sanderjd »

eru wrote: post #425
sanderjd wrote: post #423

Earlier quoted context omitted.

When things like this usually go wrong with an automated tool, it's not that it "fails", it's that it succeeds part of the way, leaving things in an inconsistent state, which is then hard to reconstruct in either direction. But you're right that it should be possible to build such things in a way that works well and very rarely screws up. But just that I don't really know of any tools that try to do anything more com…

> When things like this usually go wrong with an automated tool, it's not that it "fails", it's that it succeeds part of the way, leaving things in an inconsistent state, which is then hard to reconstruct in either direction. I can see that things can go wrong when your are half-way through constructing the new commits. But that's fine: you just leave them as they are, and let git's gc clean them up eventually automa…

Yeah I'm with you, this can be done, but again, I'm wracking my brain for an example tool that does this without being frustrating sometimes. Even just rebase itself, which is much simpler than what I'm talking about here, has footguns.

But I think this thread has convinced me that someone could almost certainly make better tools for this stuff, and now I'm just wondering why they haven't.

Re: Why SQLite does not use Git (2018)

#432

Post by account42 »

Shawnj2 wrote: post #379
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…

I do think that if there is a replacement to git in the future, it will probably have pull requests, tags, etc. built in that most git servers support but implement separately since they’re not in the standard. Alternatively, GitHub as a platform will become so standardized that they may launch their own “VCS” which is just other things bolted onto git that only work with GitHub (we’re already going there with the gi…

What? Tags are built into git. Maybe you're thinking of releases aka attaching additional files to tags.

Re: Why SQLite does not use Git (2018)

#433

Post by nullindividual »

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…

Linking two Excel files and consuming data between them requires the workbooks be open in Excel.

Power Query is no where close to what you described it as. It was not created for SharePoint or real time coauthoring. It is for getting and transforming data.

Re: Why SQLite does not use Git (2018)

#434

Post by Brian_K_White »

maccard wrote: post #319
Brian_K_White wrote: post #57

Earlier quoted context omitted.

There are all kinds of non-optimal optional ways to do things where it's valuable to have the options and have them work as well as possible vs not having the option. I guess it falls under graceful degrade vs die. It doesn't matter how much better the proper gold plated option is. If it's the only option then it's fragile and that makes it garbage.

I disagree. If the alternative is to force everyone to have a sub par experience, them I'd rather a single enforced standard that is usable.

There is no such dichotomy.

Re: Why SQLite does not use Git (2018)

#435

Post by Shawnj2 »

tentacleuno wrote: post #429
Shawnj2 wrote: post #379

Earlier quoted context omitted.

I do think that if there is a replacement to git in the future, it will probably have pull requests, tags, etc. built in that most git servers support but implement separately since they’re not in the standard. Alternatively, GitHub as a platform will become so standardized that they may launch their own “VCS” which is just other things bolted onto git that only work with GitHub (we’re already going there with the gi…

They already have the GitHub command line, actually. https://cli.github.com/

Typo that’s what I meant

Re: Why SQLite does not use Git (2018)

#436

Post by hprotagonist »

genocidicbunny wrote: post #192
hprotagonist wrote: post #54

Earlier quoted context omitted.

> The D is DVCS is a waste of effort. until the de facto centralized remote goes offline and you’re stuck with no local history …

I would love to see a DVCS that can effectively handle repos of the size I've seen. How well does DVCS work when your repo shallow copy is about 10TB?

https://github.com/microsoft/VFSForGit

better than it used to, with the caveat that git in particular is not and has never claimed to be good at versioning blobs.

Re: Why SQLite does not use Git (2018)

#437

Post by Brian_K_White »

inferiorhuman wrote: post #48
reaperducer wrote: post #34

Earlier quoted context omitted.

if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. That's pretty much the opposite of progress. At one time, 99.9% of developers used CP/M. At time, 99.9% of web was done in PHP. At one time, 99.9% of developers IBM XTs. At one time 99.9% of developers used SourceForce and SVN. Stuff changes. Monoculture is bad for the tech industry.

On the one hand I'm inclined to agree about monoculture, on the other I've worked at a company where one employee dictated that we use bzr. Basically everything was an order of magnitude more difficult through minimal fault of bzr. None of the third party tooling worked with bzr, or if something did have bzr support it was dropped ages ago. It's kind of the same situation with Github. The pain in moving away from it…

To me that just sounds like an example of the reason to avoid tight coupling.

If something breaks beacause it cares that I use git and only git, then it's that something that is broken and to be avoided, not the git alternative.

Re: Why SQLite does not use Git (2018)

#438

Post by bborud »

rstuart4133 wrote: post #414
bborud wrote: post #382

Earlier quoted context omitted.

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

> If you upgrade a shared library to fix a problem, how do you know that the application has been tested against the fixed version? Distro's like Debian solve that problem by not upgrading. The only things deemed worthy of "fixing" are security issues, and they are fixed by backporting the fix (only) to the existing shared library. Thus no API's (of any sort - even unofficial ones like screen scraping) are upgraded o…

> because the package manager can assume [...]

Right.

Re: Why SQLite does not use Git (2018)

#439

Post by brisketbbq »

blitz_skull wrote: post #362
jmull wrote: post #107

Earlier quoted context omitted.

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.

Who should have written git and fossil?

Both were written by people who had problems to solve. Should they have waited around for someone to solve their problems?

Re: Why SQLite does not use Git (2018)

#440

Post by tialaramex »

Guvante wrote: post #403
tialaramex wrote: post #281

Earlier quoted context omitted.

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…

Bjarne is quite happy to admit that we made mistakes, but that wasn't my criticism was it? I'm saying that Bjarne doesn't like to admit that Bjarne made mistakes.
Post reply on HN