this post was submitted on 16 Apr 2024
347 points (95.3% liked)
Open Source
31236 readers
212 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
In many scenarios you probably won’t notice… but also Pijul has ‘fixed’ that fundamental perfomance issue. The Patch Theory states that patches, without depending patches that would cause a conflict, should commute—i.e. patch α + patch β ≡ patch β + patch α in the same way 1 + 4 ≡ 4 + 1 (order does not matter, output is equivalent). What this eliminates is an entire class of merge conflicts & opens up new ways to handle diffing. This particular class of conflicts makes it easier to work in a distributed project as anyone can pull in anyone else’s patch at different times in project without conflicts. In practice with Git being snapshot-based & patch order mattering, this tends to cause folks to rely on a centralized, canonical Git server to merge into to be able to ask what the order should be so everyone doesn’t get stuck in their rebases/pulls (
rerere
fails a lot).It turns out there is more to version control than how fast CPU go; if we measured programming languages with the same stick, we’d all only write assembly since everything else has a performance penalty.
The way you write about this seems very evangelical.
I use git every day and I don't recall patch ordering ever being a problem.
Evangelical in that it’s documented as a theory & a paper for the concepts you can read about? Communicative properties are common in math--what’s novel is applying those properties to patches for source control compared to the older models.
Have you worked in a distributed team sharing just patches over email? If Alice pulls from Bob & then Catherine, but David reads & applies Catherine’s then Bob’s, Alice & David now have a conflict in the ordering when trying to push/pull later. I have ran into this. Or did you use a centralized, canonical (therefore not distributed) Git server with a pull request model? If you do the latter, you won’t run into the issue but you also aren’t using the distributed part of a distributed version control system (DVCS)--& most don’t since has too many issues with snapshot-based tools. This restricts the sorts of systems & team structures for source control we can even do (you need a Tvoralds dictator even for Linux’s mailing list) & we can’t really think outside the snapshot-limitations until we step outside of that snapshot bubble.
No, evangelical as in needing to tell people about it, even when they have no interest.
No.
https://feddit.uk/comment/8692603
You literally asked what I suggested. And I’m trying to do my due diligence in raising awareness for ideas I find compelling since these alternatives have yet to be any many folks’ radars …VCSs that solve issues you have yet to run into, but might someday & now you might remember you once heard about a solution online.