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

261–270 of 454 posts

Re: Why SQLite does not use Git (2018)

#261

Post by lelanthran »

SubjectToChange wrote: post #216
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.

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? Rust allows both shared and static compilation, so it's actually the opposite - Rust specifically doesn't force the use of single-binaries.

I'm struggling to interpret what it is you are saying: Go specifically forces the use of static linkage, whereas in Rust it's optional, is it not?

I am under the belief that in Rust you can opt-out of static linkage, while I know that in Go you cannot.

Are you saying that Rust doesn't allow opt-out of static linkage?

Re: Why SQLite does not use Git (2018)

#262

Post by gardenhedge »

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…

Please read the article:

This article is not a comparison between Fossil and Git.

This article is not advocating that you switch your projects away from Git.

Re: Why SQLite does not use Git (2018)

#263

Post by flohofwoe »

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 of minimal cmdline tools that do one thing right is fine and the Go-style 'monolithic exe' without runtime dependencies except the OS is also fine (and both philosophies actually don't need to collide).

The problem is all the software that depends on tons of dependencies that are brought in dynamically. Just look at Jekyll vs Hugo. I have Jekyll break regularly when something (seemingly) unrelated changes on my machine, but Hugo is just rock solid.

Or another much more annoying example: Linux executables linking with glibc and then not running on systems that don't have that particular version of glibc installed.

Re: Why SQLite does not use Git (2018)

#264

Post by gardenhedge »

junon wrote: post #240
ThinkBeat wrote: post #169

I am not a Git fan. The most perplexing to me is how huge companies spend 100.000s (1.000.000s??) of $$ to hack Git so that it will git with their needs. Like Google. One of the biggest issues seem to be the size of the repo, which takes days (?) to download and get started. Does Google contribute all their extra services / tools to make Git for work for then?

Unless you're checking out old commits, `git clone --depth=1`. Then you get close to the ideal download size for any given repo.

If that is ideal why is it not the default?

Re: Why SQLite does not use Git (2018)

#265

Post by eru »

Zacharias030 wrote: post #253
test1235 wrote: post #230

Earlier quoted context omitted.

So it looks like you're ready for a change ... What's next on the horizon?

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 useful workflow, I guess?

Re: Why SQLite does not use Git (2018)

#266

Post by csydas »

resonious wrote: post #96
bane wrote: post #41

Earlier quoted context omitted.

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…

Directories full of stuff is similar to websites with URL paths like "/site.php?page_id=18231238". Or even better when subdomains get involved and it looks like "secure3.action.domain.com/admin.php?page=123424". It technically works but is a bit ugly. Also another web analogy might be dynamic linking being similar to microservices. People want to build and ship smaller components that can be swapped out independently…

>Directories full of stuff is similar to websites with URL paths like "/site.php?page_id=18231238". Or even better when subdomains get involved and it looks like "secure3.action.domain.com/admin.php?page=123424". It technically works but is a bit ugly.

OOC, why does this stand out for you? Just to explain my curiosity, I've worked on Mac since I was a kid starting with System 6 and then going to OS X when it came out, so Apple's "your program is all in that file" just kind of made sense to me and it was really convenient to just drag a file to the trash and the app is _mostly_ gone, minus a few .plist and other config files in ~/Library.

But I _like_ the old forums and sites that still show the stuff like page_id=N; for the boards and forums I go to, it's very useful to just jump around long topics or you can play with it on your shitposting.

Plus most modern browsers truncate or hide the full URL anyways; I dislike this feature personally, but at least Safari's concise tabs are a good balance for someone like me.

Re: Why SQLite does not use Git (2018)

#267

Post by eru »

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…

It's important to distinguish between 'local disagreements' and 'social disagreements'.

The former are things that don't affect anyone else. Eg your co-workers don't care if you your remotes 'origin' and 'upstream', or 'fork' and 'origin'.

The latter are things you need to coordinate on with other people. Eg how you want your git history to look like in the end.

Re: Why SQLite does not use Git (2018)

#268

Post by maccard »

KerrAvon wrote: post #131
forrestthewoods wrote: post #49

Earlier quoted context omitted.

> and do it well If only Git did it well! Ok that’s not fair. Git is pretty okay for the Linux open source project. But it’s pretty mediocre-to-bad for everything else. The D is DVCS is a waste of effort. Almost all projects are defacto centralized. In fact the D is anti-pattern that makes things like large binary files a still unsolved problem in Git. And no Git LFS doesn’t count. Source control should be capable fo…

Counterpoint: Lots of people actually use and like the D aspect. It’s one of the best things about Git! Local git repos can be shallow or partial clones if you insist on it. You say elsewhere that a VCS should support an offline mode instead, but if that’s not a copy of the repository, how is it in any way equivalent and what exactly is the difference? I’ve never understood why people like Perforce; I’ve assumed it’s…

I like perforce. It scales significantly better than git, (running git status on a large project, or cloning one takes significantly longer via git than p4). Not having the entire history of a project locally on disk is a pro to me, not a con. P4merge is orders of magnitude better than git's. Atomically incrementing numbers for changelists are superior to sha's if the first thing you do is implement version numbers on top of git. The default workflow is sane and teachable in all of 10 minutes even to non technical people (designers, artists). I like that history is immutable - there are admin tools available if surgery is needed.

P4 isnt perfect, but it's definitely got significant advantages over git in many areas.

Re: Why SQLite does not use Git (2018)

#269

Post by eru »

I don't necessarily agree with the author, but it's still an interesting and thought-provoking write-up.

I'm also happy someone is willing to put time and effort into keeping alternatives alive: I like git, but monocultures are seldom good.

Re: Why SQLite does not use Git (2018)

#270

Post by kubanczyk »

cryptonector wrote: post #163
NBJack wrote: post #7

I think there are some legitimate criticisms of Git here. But some of them are...odd. Despite using Git in a variety of circumstances, from a local personal repo project to very large company repos, I admit I haven't run into about half of these issues. > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on…

> > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on mobile. (The preceding text in TFA makes it clear that this refers to rendering a view of history. This is in a section titled "Git does not provide good situational awareness".) Here's the thing: if you use a rebase workflow then all history will be l…

> if you want to understand your work -and also others to understand your work- it seems much better to rebase and resolve conflicts commit by commit

I do love rebase workflow and push it everywhere I can. But that's just not true.

Conflict resolution with git-rebase is just horribly implemented. Working even one conflict through a sequence of five commits is so hopelessly repetitive and error-prone operation that it makes a git-merge look almost like a sensible option.

And then the reviewer delays one more day and another conflict appears.

That eiffel tower of context switches does not improve your understanding or anyone's understanding. If it's made sane (LLMs? Yes please!) the git-merge would probably all but disappear on new projects.

Post reply on HN