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

341–350 of 454 posts

Re: Why SQLite does not use Git (2018)

#341

Post by phamilton »

Guvante wrote: post #185

I think git gets a bad rep because no one can agree how to use it. GitHub PRs vs pushing a branch, rebase vs merge are just two examples of tools that do identical things in fundamentally different ways. And the problem is none of them are wrong. Rebasing minor commits simplifies unnecessary complexity in your history. Merging preserves what actually happened which can provide insight into why changes occurred. Of co…

A philosophy that has helped me: Do what makes sense for your immediate goal and then reassess and adapt.

In practice, I actively rebase my commits in a PR with the sole focus of "What will make this easiest to review?". Then, once the review is completely I ask "What will make this easiest to operate and understand in the future?" I might squash everything together, or I might restructure into independently deployable pieces to facilitate rollback.

The point is that all these things might have different needs and it's ok to do different things at different times. But that's requires a little more judgement from individuals and is difficult to teach and enforce across larger teams.

Re: Why SQLite does not use Git (2018)

#342

Post by IshKebab »

jayski wrote: post #37
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 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 more than one thing"? You probably haven't even considered it.

I'd put it up there with "premature optimisation" as one of the most damaging programming mantras.

Re: Why SQLite does not use Git (2018)

#343

Post by 8n4vidtmkvmk »

gumby wrote: post #329
medstrom wrote: post #295

Earlier quoted context omitted.

How many people know GitHub can do that? Your comment was the first I'd heard about it.

I suspect it’s the opposite way around: most people, when they hear “git”, macroexpand it to “github” and don’t even know that there is a (more powerful) command-line interface. The peer-peer distributed nature is barely known — these days it’s a centralized client/server system. I remember the Internet connection going out at work a few years ago and developers saying they couldn’t coordinate bc github was not acces…

My partner definitely does not know the difference between Git and GitHub. He's not much of a programmer but yeah.. maybe this is like Java vs JS all over again. Or jQuery vs JS. That one makes me extra sad.

Re: Why SQLite does not use Git (2018)

#344

Post by JonChesterfield »

avgjo wrote: post #38

I've used Fossil for a private local project. It's quite a capable revision control system with a very decent web UI. Just a word of warning - make frequent backups of the backing sqlite repository database. I had upgraded fossil to make a few commits and then I inadvertently made a commit using an older version of fossil and it corrupted the fossil repo database irreparably and a few days' of work was lost. I've nev…

As a counterpoint, I've been completely unreasonable with my use of fossil. Wildly different versions on different systems, often from years apart. They get whatever binary existed when I set up the system and stay on it. Some osx, some variations of Linux, a freebsd box. I think windows if I go back far enough. Synchronising between them in ad hoc fashion.

Some repos are over a decade old. One is over 10k commits deep, another several gigabytes in size because I checked in whole dev environments.

Every now and again it told me it wanted to rebuild and that succeeded. I routinely ctrl-c it partway through a commit if I notice a typo.

It has _never_ dropped the ball on me. Fossil is by a wide margin the most reliable program I've ever used.

Re: Why SQLite does not use Git (2018)

#345

Post by FpUser »

jpc0 wrote: post #187
FpUser wrote: post #66

Earlier quoted context omitted.

Can't imagine reading code on those tiny screens.

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.

You are assuming too much about me without having a single clue.

>"What if I like vertical monitors, or want 5:4 etc."

Your choice. Mine - not to work on cell phone. This might change if they will stop crippling smartphones and let it to be hooked to a decent monitors / (future high quality display glasses)

Re: Why SQLite does not use Git (2018)

#346

Post by JonChesterfield »

nmz wrote: post #172
mbfg wrote: post #77

i guess you use what you have, and don't use what you don't have, but i don't really know when i've ever thought let me see what happened after that branch was merged into future. I do have a simple script that will list what branches were merged into the current branch in git. That is useful, so being built in, in Fossil is useful i guess. My gripe with Fossil, is not technical, it is really just who uses it? How mu…

Given that fossil is an integral part of sqlite, it will wither and die when sqlite does. It's also the perfect example and test of sqlite itself, an scm that is a one stop shop for the entirety of the project, remaining as responsive no matter the increase of the scm db itself.

Sqlite is going to outlive basically everything. That's not a serious hazard.

Re: Why SQLite does not use Git (2018)

#347

Post by qsantos »

amadeuspagel wrote: post #311
anon35 wrote: post #210

Made a list of all the revision control tools I've used over the decades, the year they were created, and the year I last used them: sccs 1973 2000 rcs 1982 2000 cvs 1990 2004 clearcase 1992 2004 perforce 1995 2011 subversion 2000 2015 mercurial 2005 2015 git 2005 present So, at least for me, they last around 15 years or so. But often time when I tell juinors that when they're my age, git will be distant a strange me…

The internet tends to lock things in. There were many languages dominant in history at some point or another, english will be the final one. There were many scripting languages, javascript will be the final one. Many networking protocols, TCP/IP the final one. Same for git. I think the only thing that might displace git is some environment for new programmers with its own version control system like glitch[1]. [1]: h…

> There were many scripting languages, javascript will be the final one

If, by “scripting languages”, you mean “browser-native languages”, WebAssembly might become a serious contender as the lingua franca for the Web in the long term.

Re: Why SQLite does not use Git (2018)

#348

Post by JonChesterfield »

_a_a_a_ wrote: post #246

> In contrast, Fossil is a single standalone binary which is installed by putting it on $PATH. ... It manages a community server with wiki, bug tracking, and forums, provides packaged ... Standing up a community server for Fossil takes minutes. Let's see... About a year ago I try to set up fossil because I wanted the issue tracking it supposedly provides. I'm already using git for VC and will stick with it. Spend sev…

Make a repo. That's a file that lives wherever. Go to some directory, fossil open filename. Now you have a working directory. Type fossil ui, now you're looking at it in a browser.

It sounds like you want a version running on a machine that multiple people log into to access the UI. That I don't know how to set up. Spinning up the UI locally makes a lot more sense to me that sharing a single instance with the world.

Re: Why SQLite does not use Git (2018)

#349

Post by hiccuphippo »

toastal wrote: post #238
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 will be ready when it support the ability to email patches as a universal fallback method of submitting patches upstream for those that do not wish to create an account with a given service.

Isn't the patch/diff format already universal? I mean the one you generate with diff [0] and apply with patch [1]. You don't need the vcs to generate it.

[0] https://linux.die.net/man/1/diff

[1] https://linux.die.net/man/1/patch

Re: Why SQLite does not use Git (2018)

#350

Post by olddustytrail »

forrestthewoods wrote: post #170
happymellon wrote: post #156

Earlier quoted context omitted.

The world wants you to use git for binary file versioning? I have never encountered that. Binary files are generally kept in something like SharePoint, where it is SharePoint which is then hated by everyone. It's interesting that regardless of the tool, everyone seems to hate it. Perhaps if all tools are wrong, you are trying to force a bad usecase?

> you are trying to force a bad usecase The world has non-text files that require version control support. Version control systems are mostly bad-to-terrible for anything other than source code. Implying that the use case is wrong is borderline offensive. It’d be nice if there were some artist/designer friendly version control systems. I can teach someone who has never even heard of version control how to use Perforc…

Then use Perforce? Why are you complaining that something doesn't exist and then literally naming it in the next sentence!
Post reply on HN