IAm_A_Complete_Idiot @ IAm_A_Complete_Idiot @sh.itjust.works

Posts

0

Comments

63

Joined

2 yr. ago

The data model there is fundamentally different. That would break how git would work because operations that worked one way before would now no longer work that way. You'd functionally have rewritten and mapped all the old functionality to new functionality with subtle differences, but at that point is it even git? You have a wrapper with similar but subtly different commands and that's it. It's like saying "instead of reinventing functionality by building both ext4 and btrfs, why don't we just improve ext4"?

The two are practically entirely different.

It being objectively better then SVN or CVS doesn't mean that it's the best we can do. Git has all sorts of non-ideal behaviors that other VCS's don't. Pijul's data structure for instance is inherently different from git and it can't be retrofitted on top. Making tooling only support git effectively kills off any potential competitors that could be superior to git.

One example is pijul specifically let's you get away from the idea that moving commits between branches changes their identity, because pijul builds a tree of diffs. If two subtrees of diffs are distinct, they can always be applied without changing identity of those diffs. This means "cherry picking" a commit and then merging a commit doesn't effectively merge that commit twice resulting in a merge conflict.

That's one example how one VCS can be better.

Not OP, but personally yes. Every code forge supporting only git just further enforces git's monopoly on the VCS space. Git isn't perfect, nor should be treated as perfect.

The above is probably the reason why so many alternative VCS's have to cludge themselves onto git's file format despite likely being better served with their own.

Interesting new VCS's, all supporting their own native format as well for various reasons:

• pijul
• sapling
• jujutsu

Sapling is developed by meta, jujutsu by an engineer at Google. Pijul is not tied to any company and was developed by an academic iirc. If you're okay with not new:

• mercurial
• fossil
• darcs

VCS's are still being itterated on and tooling being super git centric hurts that.

Linus has stepped away from kernel development before, and probably will again. Life continues on.

Second person excited for bcachefs, I'm planning on swapping over as soon as it supports scrubbing.

Right, but squashed commits don't scale for large PRs. You could argue that large PRs should be avoided, but sometimes they make sense. And in the case where you do have a large PR, a commit by commit review makes a lot of sense to keep your history clean.

Large features that are relatively isolated from the rest of the codebase make perfect sense to do in a different branch before merging it in - you don't merge in half broken code. Squashing a large feature into one commit gets rid of any useful history that branch may have had.

Yeah, but phabricator and Gerrit are entirely separate workflows from GitHub, and a lot of people prefer that workflow because it leads to encouraging better histories and reviews. It helps you in getting rid of the "fixed typos" type of commits, while still letting you make larger PRs.

GitHub obviously does let you keep a clean git history, but the code review workflow in GH just doesn't encourage reviewing commits.

How much of that is what GitHub encourages and how much of that is what Users prefer? Plenty of users seem to enjoy phabricator / Gerrit for code review in practice precisely because of their workflows.

It's not battle tested on massive projects nor does it have the prior mindshare git has. It doesn't have a lot of tooling either. (Does any CI/CD system support pijul?) It has nice properties, but ultimately git with all it's terrible warts is well understood.

Also, GitHub PRs atleast to me feel like they encourage reviewing changes by the total diff of the entire PR, and not each commit. I don't want a slog of commits that don't add any value - it just makes doing things like reverts more annoying. Stuff like Gerrit and phabricator enforce reviews by making you review individual commits / changes / whatever you want to call them and not branch diffs.

Yeah, good commit messages are about intent and context of a change - not what the change itself is. We can look at the diff for that. Just write a single line or two summarizing what the commit does, and everything else should be adding context on top that doesn't directly exist in the codebase.

Not having to swap over to a ticketing system just to see the context of a change is really nice (Or to add context on why changes are done a certain way). One line that says what you changed, then any context such as why it was done that way, and important notes about that change works wonders. It's pretty much the exact model the Linux kernel uses, and it makes looking at changes great for anyone down the line.

According to the benchmark in the article it's already way faster at n = 1000. I think you're overestimating the cost of multiplication relative to just cutting down n logarithmically.

log_2(1000) = roughly a growth factor of 10. 2000 would be 11, and 4000 would be 12. Logs are crazy.

The version control system, and all the associated code isn't tied to any system - yes.

It looks like on blender's website there's 6 entities on there, and one of them does seem to be an individual fwiw. Here's his website: https://aras-p.info/.

The rest all seem to be corporations though - meta, aws, some game company I've never heard of, AMD, and epic.

I just checked their financial report for 2022 and it looks like 50% came from patron funding (which looks like entirely companies like Google), 5% from epics grant, and then 10% corporate membership. 20% came from individuals, and the rest from random other miscellaneous things like the blender market. If you search blender foundation annual report 2022, the finances breakdown will be near the end of the slides.

When you make a project with git, what you're doing is essentially making a database to control a sequence of changes (or history) that build up your codebase. You can send this database to someone else (or in other words they can clone it), and they can make their own changes on top. If they want to send you changes back, they can send you "patches" to apply on your own database (or rather, your own history).

Note: everything here is decentralized. Everyone has the entire history, and they send history they want others to have. Now, this can be a hassle with many developers involved. You can imagine sending everyone patches, and them putting it into their own tree, and vice versa. It's a pain for coordination. So in practice what ends up happening is we have a few (or often, one) repo that works as a source of truth. Everyone sends patches to that repo - and pulls down patches from that repo. That's where code forges like GitHub come in. Their job is to control this source of truth repo, and essentially coordinate what patches are "officially" in the code.

In practice, even things like the Linux kernel have sources of truth. Linus's tree is the "true" Linux, all the maintainers have their own tree that works as the source of truth for their own version of Linux (which they send changes back to Linus when ready), and so on. Your company might have their own repo for their internal project to send to the maintainers as well.

In practice that means everyone has a copy of the entire repo, but we designate one repo as the real one for the project at hand. This entire (somewhat convoluted mess) is just a way to decide - "where do I get my changes from". Sending your changes to everyone doesn't scale, so in practice we just choose who everyone coordinates with.

Git is completely decentralized (it's just a database - and everyone has their own copy), but project development isn't. Code forges like GitHub just represent that.

Wikimedia foundation is, none of the other things I listed are.

I think the key there is funding from big companies. There's tons of standards and the like in which big companies take part - both in terms of code and financial support. Big projects like the rust compiler, the Linux kernel, blender, etc. all seem to have a lot of code and money coming in from big companies. Sadly there's only so much you can get from individuals - pretty much the only success story I know of is the wikimedia foundation.