> Even I have to use git because who uses anything else?

Git compatibility is a great way around this problem. I have been enjoying Jujutsu lately.

Not really. The real innovation of a lot of these alternative DVCS systems is that they free the state of the source from being dependent on the history that got you there. Such that applying patches A & B in that order is the same as applying B' & A' -- it results in the same tree. Git, on the other hand, hashes the actual list of changes to the state identifier, which is why rebasing results in a different git hash id.

So long as you require git compatibility, you're kinda stuck with git's view of what history looks like. Which is rather the point.

Newbie jj convert here.

jj is not patch based, like pijul, but snapshots, like git.

A sibling commentor points out the change id stored by jj: it is true that at the moment, this isn't really exportable to git in a native way. However, there is a path forward here, and it may come to pass. Until then, systems like Gerrit or Phabricator work better with jj than systems like GitHub.

However, all is not lost there either: tooling like spr[1] allows you to map between the two universes.

At my job, at least one person was using jj for six months at work without any of the rest of us being the wiser. Some of the rest of us are trying it out. A really nice thing about jj is that you can use it without anyone else needing to, thanks to the git interop.

1: https://github.com/getcord/spr

That is definitely a tradeoff. On the other hand, the history of all human progress is a history of path dependence. Constraints spur creativity and Jujutsu works extremely well.

(I've worked with the main author of Jujutsu before. Also, having worked on Mercurial for many years, I have my biases about how source control should work. Jujutsu's workflow is very similar to Mercurial's, with some rather stunning improvements on it.)

Jujutsu uses change IDs, which are an abstraction over commit IDs, that are stable over operations like rebasing.

Supporting conversion with some lossy tendencies is a good idea, but maintaining compatibility will stifle innovation as al bugs & design decisions cannot be fundamentally worked around.

Adjacent, I heard folks praising Forgejo for its Actions & Microsoft GitHub compatibility, but that means you are still left with the same YAML spaghetti and its other limitations. What would have been nice is something better for CI--something that prompts the project to want to switch to get a better experience. As such, while I agree with the moral reasons to switch to non-proprietary software, the reason for switching is philosophical, not philosophical + technical. I feel being a wrapper around Git or Git compatibility will likely fall in this category rather than being more compelling.

but you know git and github are not the same thing right?

For the vast majority of OSS projects, you're much better off using Git and GitHub in terms of drawing attention and attracting contributors.

git != github

To be fair, many git maintainers are or have been github employees and git is officially hosted on github.

That social media code forge is not the same as its underlying version control system. They are different things & we should support making folk not equate the two.

There is empirical evidence that git is diabolical: Git can be thought of as an experiment in how to make an API GUI-proof. There is no possible direct manipulation visual representation of git operations that doesn't dumb it down.

I content that magit, while not a GUI, pretty much transcends git’s CLI.

GUIs will only ever tackle a subset of git’s functionality since if you’re already a power user you’ll be comfortable with the command line.

I'll give magit a try. But imagine if you had to use TEX to format anything more than trivial documents. It makes me want to get a Vision Pro and see if a direct manipulation git UI could access the full potential but with visual discoverability and safety.

I find gitx really helpful at understanding what's going on in git. Especially its ability to drag branches around the tree shows you that branches are just labels, they aren't the actual code. It doesn't do everything, but what it does do certainly isn't dumbed down.

You definitely need a gui to do partial commits. git add -P is just horrible to use.

> Even I have to use git because who uses anything else?

It's pretty widely not used in the games industry because its support for media files is poor, it's pretty difficult to train artists to use it, the integration with game engines is pretty poor, git LFS is a layer of complication on a system that already has UX that's difficult for artists, git LFS hosting is an additional can of worms, there's essentially no file/directory-level permissions for managing contract work (and doing so with submodules+LFS is complicated).

Do you know of any FOSS alternatives that handle that stuff better (specifically binary asset handling and permissions)?

Pijul does binary files natively, actually. Permissions aren't hard to add, if anybody had a real-world case I'd be happy to help.

the places where I've seen people leverage the folder-level permissions in Perforce (in the games industry) would be like: a contractor that provides art would only have access to the portions of the project that relate to the art they're working on but not the code; translators might have read access on one directory and write access on another directory. In academic settings I've seen Perforce used such that an instructor has read-write access on a directory and students have read-only access on the directory, and then each student has a subdirectory where they have read-write access and everyone else has read access, so that everyone can play each other's games. You can do stuff like this in git with submodules but it's somewhat complicated and difficult to teach to non-programmers. It's not really clear what the target audience is for the project. The mathematical/theoretical foundations are clear, but the target audience is unclear, so I'm not sure if these are use-cases that you consider to be within the project's scope or not; just sharing how I've seen the permissions models used in the games industry.

oh and nearly everyone hates using perforce and its clients p4v and the p4 command line, so it’s not like there’s no appetite for change. There’s very much an appetite to see Perforce unseated, because it costs money and is also bad.

some indies use Subversion, but Perforce is the industry standard.

There are many people who work on open source professionally, but as a hobbyist programmer I find it odd to worry about Copilot automating my “job.” This is like complaining that your dishwasher or robot vacuum cleaner automates your job because you don’t do the work by hand anymore.

If you’re getting paid then it makes some sense to worry about automation, but if you’re not, automation is good. You can do more. The community can do more. We can take on more ambitious projects.

If you are a hobbyist programmer, it is not your "job" . So it is not automating your job for the moment but the professional programmers' job, isn't it?

Yes, what I'm trying to get across is that open source programming is often not a job. It can become a job, but I want to leave room for it being ok not to be a job.