The biggest issue left is setting up mailing list infrastructure that will work with the service. If anyone has #opensmtpd and #sympa experience, please ping me. 🥰
+100 to this: Git is the most user-hostile piece of software I've ever tried to teach (and I've taught people Emacs). It's a significant barrier to entry for many people who really want to learn to program, and those who claim otherwise are textbook examples of survivor bias. https://mastodon.social/deck/@tess/110856324920882032
@forgejo Proposal to extend /organisation/repository URL structure to /organisation/project/repository to limit pollution of global organisation namespace.
Concerning my toot from a few days ago concerning more "well-bounded" #dvcs patch workflows, I just discovered #pijul, which seeks to make applying changes commutative (ie the order doesn't matter) based on "theory of patches", "merge correctness", "partial clones" and "first-class conflicts":
"In Pijul, independent changes can be applied in any order without changing the result or the version's identifier. This makes Pijul significantly simpler than workflows using git rebase or hg transplant. Pijul has a branch-like feature called "channels", but these are not as important as in other systems. For example, so-called feature branches are often just changes in Pijul. Keeping your history clean is the default."
Many people seem to agree that part of what makes #git (& #dvcs in general) so difficult to get a really effective handle on is that applying patches is a lot like working with pre-processor macros (ie #define in #C), and that there oughta be a more well-bounded, lexically concise means of code collaboration to establish. But the only work I've seen in this direction is Arun Isaac's tree-diff[1]. #TreeSitter[2] seems like a tool that can greatly ease experimentation in this direction, but what other work has been done on this problem?