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

271–280 of 454 posts

Re: Why SQLite does not use Git (2018)

#271

Post by flohofwoe »

willdr wrote: post #198
NikkiA wrote: post #109

Earlier quoted context omitted.

Actually it does, because with the windows git it includes it's own copy of ssh and bash, both of which will clash and fight with msys and/or other ssh installs - including the copy of ssh that microsoft themselves tuck away in \windows\system32 it's quite 'normal' for git-for-windows' ssh-agent to completely disable ssh-agent from working properly system-wide because it ends up pointing things at the wrong ssh-agent…

But a developer isn't using Windows.

Pretty much all game development still happens on Windows because that's where all (or at least most of) the gamedev tools and middleware libraries are.

Re: Why SQLite does not use Git (2018)

#272

Post by glandium »

nmz wrote: post #213
somenewaccount1 wrote: post #59

>Git focuses on individual branches, because that is exactly what you want for a highly-distributed bazaar-style project such as Linux. Linus Torvalds does not want to see every check-in by every contributor to Linux: such extreme visibility does not scale well. Contrast Fossil, which was written for the cathedral-style SQLite project and its handful of active committers Ugh...so after all that fanfare of how amazing…

I think [0] indicates that it does scale quite well, you can even test by comparing the 2. You can go from cloning to pushing on a repo in half the time. There's branches as well, so while the /timeline[1] seems too busy, you can always drop back to a forum or the bug tracker, which it has already. time fossil clone https://fossil-scm.org/ time git clone https://github.com/drhsqlite/fossil-mirror My results were foss…

There is something fishy with the repo on github.

  git repack -a -f -d
  du -sh .git
   65M    .git
It's also significantly faster to clone after the repack:

  time git clone --mirror https://github.com/drhsqlite/fossil-mirror
  65.10s user 21.22s system 35% cpu 4:05.92 total

  time git clone --no-local fossil-mirror fossil-no-repack
  26.92s user 2.99s system 155% cpu 19.190 total

  git -C fossil-mirror.git repack -a -f -d
  time git clone --no-local fossil-mirror fossil-repack
  5.42s user 1.18s system 211% cpu 3.121 total
Edit: took new measurements with --mirror on the first clone so that the "local" clones actually get all the branches.

Also:

  git gc --aggressive
  du -sh .git
   42M    .git

Re: Why SQLite does not use Git (2018)

#273

Post by bborud »

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…

Why do you think it is a strength that git is "not bundling the kitchen sink"? I'd like to understand better why other people prefer kitchen sink vs multiple binaries.

I am in two minds when it comes to this. A lot of (server) software I write bundles server, client and tools in the same binary. I also embed the API documentation, the OpenAPI files, the documentation and sometimes related documentation in the binary so that it can be served on an endpoint on the server or extracted.

So you have one binary, statically linked whenever possible, that contains everything you will need. And where everything is the same release as everything else, so there are no chances you'll end up with different versions of client, server, documentation, tooling etc.

The binary size doesn't concern me. I could easily increase the binary size tenfold, and it still wouldn't be a problem for the software I write. I don't think binary size is a big concern today since so much software "splats" files all over your system anyway (which I think is a horrific way to do things), so footprints tend to be somewhat large anyway.

What occasionally does concern me is that this might be confusing to the user. But it is possible to make things confusing for the user even if a piece of software is more focused (ie does "one thing"). One example is CLI utilities that have multiple screenfuls of `--help` output. To me, that's poor usability. Users end up resizing terminal windows, scrolling back and forth (when you deal with related options) and perhaps even resorting to grep or less to find what you are looking for.

I try to mitigate this by always structuring CLI applications with commands and subcommands. Where you can do --help at each level. Quite a few CLI applications do this and I think it helps.

This summer I wrote the first piece of software in perhaps half a decade that has separate binaries for the client and the server. Because I want to share the client code, but not the server code. While the split was unrelated to usability, I've started asking myself if this presents a better user experience. I haven't really been able to conclude.

Re: Why SQLite does not use Git (2018)

#274

Post by maccard »

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…

Even not in games, moving away for months at a time with no coordination is a recipe for disaster.

Re: Why SQLite does not use Git (2018)

#275

Post by josephg »

ogurechny wrote: post #183
josephg wrote: post #151

Earlier quoted context omitted.

> Either people responsible for packaging have some vague or precise understanding of how their code is used, on which systems, what are its dependencies But with python it’s a total mess. I’ve been using automatic1111 lately to generate stable diffusion images. The tool maintains multiple multi-hundred line script files for each OS which try to guess the correct version of all the dependencies to download and instal…

Then the author of that script is the one who deals with said complexity in that specific manner, either because of upstream inability to provide releases for every combination of operating system and hardware, or because some people are strictly focused on hard problems in their part of implementation, or something else. A package manager with “well designed” packages still can't define what they do, invent program…

> A package manager with “well designed” packages still can't define what they do, invent program logic and behavior.

The solution to this is easy and widespread. Just ship scripts with the package which allow it to compile and configure itself for the host system. Apt, npm, homebrew and cargo all allow packages to do this when necessary.

A well designed PyTorch package (in a well designed package manager) could contain a stub that, when installed, looks at the host system and select and locally installs the correct version of the PyTorch binary based on its environment and configuration.

This should be the job of the PyTorch package. Not the job of every single downstream consumer of PyTorch to handle independently.

Re: Why SQLite does not use Git (2018)

#276

Post by forrestthewoods »

lelanthran wrote: post #261
SubjectToChange wrote: post #216

Earlier quoted context omitted.

Either way “Rust is helping” is true. And given that Go is a managed language it never really factored into the shared library debate to begin with, whereas Rust forces the issue.

> Either way “Rust is helping” is true. Maybe, but it's misleading. Using the assertion that "$FOO made $BAR popular" when $FOO contributed 1% of that effort and $BAZ contributed the other 99% is enough to make most people consider the original statement inaccurate. > And given that Go is a managed language it never really factored into the shared library debate to begin with, whereas Rust forces the issue. How so? R…

> Using the assertion that "$FOO made $BAR popular"

Thankfully that’s not what I said! This sub-thread is very silly.

FWIW Rust is exceptionally bad at dynamic/shared libraries. There’s a kajillion Rust CLI tools and approximately all of them are single file executables. It’s great.

I have lots of experience with Rust, the Rust community, and a smorgasbords of “rewrite it in Rust” tools. I personally have zero experience with Go, it’s community, and afaik Go tools. I’m sure I’ve used something written in Go without realizing it. YMMV.

Re: Why SQLite does not use Git (2018)

#277

Post by bborud »

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.

I think the "Unix philosophy" is best applied to problems that indeed can be de-composed into clear discrete steps. In fact, that's the metric I use when I write command line utilities: does this make sense in a pipe?

There are a lot of things where this isn't very practical. For instance, imagine building a web server that consists of a couple of dozen discrete utilities that are then cobbled together using pipes. Or even implementing the core feature set of Git in this manner. Would it be practical? Would it be better if Git was an enormous shellscript that connected all of these "things" into an application? What does that give you? And what would be the cost?

How would you do SQLite (the CLI application) as a bunch of discrete commands?

Re: Why SQLite does not use Git (2018)

#278

Post by tester756 »

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…

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

Re: Why SQLite does not use Git (2018)

#279

Post by seba_dos1 »

eru wrote: post #265
Zacharias030 wrote: post #253

Earlier quoted context omitted.

Generally git‘s support for a stacked PR workflow is poor [0], but imho that is the future of team collab (git is great for very asynchronously built projects, like the linux kernel). I also wonder, how much better git could be if it was based on DAGs not trees (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) and corollarily I‘d like to rebase subtrees…

> I also wonder, how much better git could be if it was based on DAGs not trees [...] Git generally supports DAGs. > [...] corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches. Rebasing is something you do to the commit graph, which is a DAG. Branches only come in incidentally. Branches in git are really just mutable pointer to immutable commits. What you are describing is probably some usefu…

Not only it's useful, it's as easy to do in git as typing `git rebase -r`. Recently it even gained support for rewriting branch pointers in the process.

Re: Why SQLite does not use Git (2018)

#280

Post by sgbeal »

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.

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

Anecdote: when i first met Richard in 2011, after having contributed to Fossil since 2008, i asked him why he chose to implement fossil as a monolithic app instead of as a library. His answer was, "because I wanted it working next week instead of next month." It was a matter of expedience and rewriting it now would be a major undertaking for little benefit.

Reimplementing fossil as a library is a years-long undertaking (literally) and is not something we're interested in doing directly within the Fossil project, but is something i maintain as a semi-third-party effort, along with a handful of other Fossil contributors, over at https://fossil.wanderinghorse.net/r/libfossil>.

Post reply on HN