I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue.
I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git cli hands down. I'm 100% on the path of least resistance when it comes to tool adoption.
I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git.
I have used it already for a few years and can't for the life of me figure out how to solve problems with it. I just have a bunch of aliases that abstract away for the inconsistency of its commands.
Now, I switched to `jj` a month ago and basically, I have learned around 60%-ish of it. And more importantly, I have gotten out of a bunch of serious trouble (you can UNDO!!!!) already.
But if this rant is not enough:
* You can UNDO. Everything. That is the major thing
* You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice.
* The command made sense
* Nobody else knows you use `jj`, so no barrier to adoption.
* Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT!
The major troubles:
* Not yet support for major tools, ides for it. It stays in `detached head` which is not as nice as showing the current branch on IDEs, and when you are fixing conflicts some tools do not get the diffs.
* No mature UI tool. I use `gg` which is fine enough
But the above is just temporal problems. Git will never be `fixed` or improved, so is pain forever.
> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git.
Right? I even started with git, and had been somewhat comfortable with it for years. Then I joined a mercurial shop, and was more proficient with `hg` in 1 month than I had been with `git` after 5 years. It ruined me on git forever, I can't see it as anything other than a mess of wrong abstractions.
And unfortunately, these days I'm back using git with the rest of the world. Can't wait for the day when Jetbrains gets a good plugin for either `jj` or `sapling`, and I never have to google another git command again ...
I just use the CLI, even when using IntelliJ. I may be wrong, but JJ seems to have recently moved to a new model where your most recent change is (always?) stored in git as "unstaged". That means when you use an editor, you can be using the CLI to add a description, diff, or other things, and the editor will still show all the UI hints about changes, let you see the diffs there, revert there, etc. You can blame, see history, everything. There's almost no need for a dedicated plugin.
When I first started using jj, I remember just doing a "jj st" would commit everything and I'd lose all my editor support. It was pretty much the only part that got worse after switching. And now it's "fixed". If anyone knows more about jj than me, I'd love to know if I'm right about this, or just hallucinating. :D
I’ve also configured my jj to use the goland/intellij terminal command for diff viewing and conflict resolution, so I can still use the (imo great) visual tooling built into JetBrains IDEs.
I would never work with hg anymore since and I consider git much and much more flexible from both user and scripting perspective. Yes, git also suffers of command inconsistency, and unfortunately it seems to be never fixed.
> You can UNDO. Everything. That is the major thing
Everything is what? The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset. Maybe rebase in mid-rebase is a way to lose some changes so one has re-rebase again (it's really annoying, but reflog holds all rebase changes if I recall). I can't really see what you mean.
> You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice.
It's nice. I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage.
> The command made sense
It's nice.
> Nobody else knows you use `jj`, so no barrier to adoption.
It's really nice, but I'm not sure whether I understand it, but does it work as a front-end tool over git/other VCS?
> Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT!
I don't get it. What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode. Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?
Generally, most things jj does can be done in Git, it's just much more pleasant / seamless / consistent in jj - maybe with the exception of the "Working on Two Things at the Same Time" pattern[0], that one might be really hard to achieve in Git.
> but does it work as a front-end tool over git/other VCS?
citing from the article
> Before we dive in, one last thing you should take note of, is that most people use jj with its Git backend. You can use jj with your existing Git repos and reap its benefits in a way that is completely transparent to others you’re collaborating with. Effectively, you can treat it like a Git frontend.
> I don't get it. What does make rebase hard?
It's hard when you work on a set of stacked PRs and make frequent changes to arbitrary PRs in that stack, because every time you make a change, you have to manually rebase and push all of the other PRs. There's SaaS's specifically built and used for solving this problem in Git[1].
Maybe hard is the wrong word, it's just annoying and tedious. jj makes this completely seamless, as shown in the article[2].
Regarding the rebase thing, I guess it's more a matter of habit. Stacked branches indeed may be tedious and may be annoying to rebase, agree. I implemented a shell script to rebase branch trees on top of a new base that would cover stacked branches as well. It covered all my needs like resolving conflicts, concluding or aborting the branch tree rebase and so on. Of course, it would be nice to have such a right-done thing right in git. But as of now, if I understand what jj is, it seems like I can shell-script some of its features myself. Still a happy git user.
Not interactions affecting remotes (you can't unpush a commit). Configuration is also not tracked. Neither are ignored files.
You can undo changes in the working copy, rebases, splits, squashes, etc.
> The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset.
Files added to the index can be recovered at least, but it's not easy to find them. The bigger problem is if you have not added them to the index and run e.g. `git reset --hard`. You can't undo that (via Git, but maybe via your IDE or your file system).
It's also about ease of use. I know you can undo a lot of things by using Git's reflogs, but it's not easy to e.g. undo a `git rebase --update-refs` that update many branches.
> I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage.
Yes, Jujutsu also supports that (`jj workspace`), but IMO, it's nice to not have to use them just because your working copy is dirty.
> What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode.
I've worked on the `git rebase` itself, so it's not like I don't know how to use it. Some things that I think are wrong with it:
* Without `--update-refs`, it only rebases a single branch. That's basically never what I want when I have branches pointing to other rebased commits.
* It's not able to rebase more than one head (no trees of commits)
* Doesn't rebase merge commits properly. Instead, it redoes the merge, discarding any conflict resolutions. (Yes, I know about rerere.)
> Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?
Mostly that it's so stateful. While doing an interactive rebase (e.g. editing a commit), you're in a state where you can't easily check out another commit, for example. If you run into conflicts, you have to finish resolving all conflicts in the stack of commits, or you have to abort the whole rebase (throwing away any previous conflict resolutions).
Again, it will be easier to understand if you just try using Jujutsu for a few days.
> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git.
IMO Mercurial did a lot of this to themselves. I also preferred it at first but switched away from it due to their stance on no in-repo branching. They, of course, also lost due to git's author and network effects (github), but it wasn't all just "market forces".
jj git push -c <changeid> will create a bookmark for you and automatically give it a random name. Most folks who do this configure it to add a prefix, often a username.
The thing about jj is that it doesn't actually enable any new capabilities. I tell people to use emacs or vim or vscode or whatever instead of notepad because it gives them new capabilities, things that are simply unavailable unless you're talking to an LSP or running a full-powered scripting engine. jj doesn't make anything possible the way going from notepad to a real editor does. What jj does do is it makes everything so much easier that you can now actually use all of those features that git theoretically gave you. Rebases? No more fiddling, no more wedges, no more digging through the reflog because you fat-fingered something, you just go `jj rebase` and... that's it. And if you get it wrong, you just do `jj undo` and... that's it. And if you just had a six hour manic coding marathon without committing anything and now you want to spread its batch of changes back down through your patch stack, you just do `jj absorb` and... that's it. It's not the difference between notepad and emacs where you're going from no LSP to LSP, it's the difference between emacs@2016 where LSP support is a week-long adventure and emacs@2024 where LSP support is five lines copy-pasted out of the info page.
As a source control expert and jj's number one fan [1], I would count being able to defer merge conflict resolution as a new capability, FWIW. In general I think jj's greater than the sum of its (very good) parts because of how its features work together to create a coherent and pleasant user experience.
I guess I was thinking in terms of the patches you push up to github. `jj` is a joy to use and it absolutely enables me to implement workflows that I wouldn't even vaguely consider without it helping me; the big one I think of is the one where you work in a merged dir with like six parents and use `jj absorb` to instantly spread your changes out to the different PRs. I've been forced to do that in git. It was a nightmare and took me two days. Not impossible! Just utterly impractical. `jj` takes end results that were theoretically-possible-but-practically-infeasible and makes them usable. Which I suppose counts as a new capability from the UX perspective. :P
Absolutely! jj is a real advancement in the state of the art. I think it's the second time in the history of source control where the authors of a new system have spent a long time working on existing systems + deploying them at scale, and have brought their full expertise to bear on the design of the new system.
(The first was BitKeeper, which also was a tremendous achievement.)
> In February 2000, they contacted Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999), and asked if he'd like to work on this new project. Coincidentally, at the time Karl was already discussing a design for a new version control system with his friend Jim Blandy. In 1995, the two had started Cyclic Software, a company providing CVS support contracts, and although they later sold the business, they still used CVS every day at their jobs
You may recognize Jim as one of the authors of Programming Rust.
jj is not just a new interface for git, it has a lot of new and powerful features to offer, even when you're using the git backend with a colocated repo.
Just to name a few:
- deferred conflict resolution
- The very expressive revset language
- the op log and ability to undo any operation
Many things that you can do with the git cli are significantly easier and in some cases comparatively effortless using jj. If all you do is git add and git commit then you probably aren't missing out on much, but if you ever split or rebase commits you should definitely try jj.
I switched from git to jj a few months ago, so I may have some insight.
I used it at work, where everyone used git, and there were 0 issues.
What I really like about it is how changes are sort of soft committed right away and, when I checkout a different branch or change, I don’t need to stash my changes and remember the stack of stashes.
Rebasing and merging feel a little easier, but that might just be because “ours” and “theirs” doesn’t get flipped during rebasing.
I also like the ability to checkout an old commit, make a change to it, then have all my more recent commits automatically get rebased (not exactly what happens, but the analogy works)
All in all, it’s a solid, compatible, incremental step forward in VCS.
The only tangible downside for me is that it doesn’t support git hooks
> I also like the ability to checkout an old commit, make a change to it, then have all my more recent commits automatically get rebased (not exactly what happens, but the analogy works)
Can anyone comment on how Jujutsu "rebases" multiple commits at once vs. git prompting each one be signed (eg. touch Yubikey), and how it looks afterward in git?
One of the main innovations in how `jj` works (in my opinion at least) is that has a concept of "immutability" for commits, which if I recall correctly is configurable with an arbitrary filter in the config, but the default (which I've never messed with personally) essentially considers commits in tracked branches from remotes to be "immutable", meaning that anything purely local is "mutable". When you run a command to try to change any immutable commits, it will refuse unless you manually opt-in with `--allow-immutable`. This makes it super easy to clean up the commit history from local development without having to worry about accidentally putting stuff in a state where there will be conflicts when you try to sync the changes with a remote later.
I think what they're the parent commenter is referring is being able to make changes to older "mutable" commits without having to do a rebase. I'm not sure I find the description of this as being similar to an "automatic rebase" super helpful personally; the way I'd personally describe it is being able to do the equivalent of "git commit --amend" on any commit with a built-in safety check to prevent this from accidentally modifying commits pushed to remote branches that you need to explicitly override if you want to ignore it.
> the default (which I've never messed with personally) essentially considers commits in tracked branches from remotes to be "immutable", meaning that anything purely local is "mutable"
The default for what's immutable is actually `main` together with untracked remote branches [1]. I agree that what you suggested should be the default though. You can change it by adding this line to your `jj` config:
So the reason this isn't the default is that often you'll be amending and force pushing tracked remote bookmarks.
There are several use cases for bookmarks/branches that are a bit muddled, which suggests a deeper theory of bookmarks that should inform the user experience. One of the Jujutsu developers had a neat post on the Discord [1] talking about how "bookmarks must be data-flow edges: think mutability, variance, polarity, etc." This sounds generally right to me, though turning this into a fleshed-out theory and then into a good user experience is a bit of a daunting challenge.
Yeah. In Mercurial the set of immutable heads is state that's stored in the repository. In Jujutsu this is done via a revset, which is a really clever approach.
If you require a physical touch for every sign operation on your YubiKey and you sign all your commits, you are going to have a bad time with jujutsu. That is somewhat unavoidable. If you are open to caching your credentials and only requiring a physical touch once every so often, this pain goes away entirely. If a physical touch for every sign is nonnegotiable, this probably isn't going to be a tool that works for you.
Jujutsu rebases multiple commits at once almost exactly the same way git does it. The three huge improvements are: 1) rebases happen automatically for descendent commits when their parents are modified, 2) rebases happen entirely in-memory and so don't require filesystem operations, which is an enormous performance benefit, and 3) rebase conflicts are a first-class citizen and doesn't require interrupting everything to drop you into a wedged rebase so you can fix it.
The third aspect combined with the first one means you can just jump to where a rebase conflict occurred, fix it, and… you're done. All the children are fixed for you automatically. If there were more, you can fix them up in the order that makes sense to you and you don't need to completely finish before being able to jump around elsewhere in the repo.
So, I've felt pretty much like you - that is, I was happy with git, never really had major problems, and was generally content. Which meant that even though Jujutsu was on my radar for a while, it took me until now to take it for a spin.
In practice, for most bits and purposes, Jujutsu is just designed really well around a core set of primitives, which you use to achieve basically all your use-cases, which in git are spread across many fairly "special-case" features. This means that arbitrary "change tree modification" are pretty trivial.
The easiness of jumping into non-branch-tips and editing them with descendants automatically rebasing is also nice, to me, and fits in well with my workflow. Stacked PRs[0] are much less annoying than in Git thanks to auto-rebase as well.
Finally, I think the "Working on Two Things at the Same Time"[1] pattern is not easy (if even possible?) to achieve with git.
But all in all, as I wrote in the article's conclusion, the reason to use Jujutsu is that it just makes your VCS usage more pleasant, while generally not interfering with anything else as it effectively works as a git frontend.
I've switched over to using it pretty much exclusively over git directly. While there are a number of minor things that I prefer about it over git, these are the two main ones for me personally:
* If I don't pass `--allow-immutable`, trying to run a history-rewriting command will immediately fail if it would touch a commit that's present on a tracked branch from a remote. When using git directly, it's way easier to accidentally make changes during a rebase that conflict with remotes and then requires me to go back and fix it when I can't do a fast forward to sync the changes
*Conflicts are part of the state of individual commits rather than a property of an ongoing operation. When an operation produces a conflict in one or more commits, I can still do whatever development (or make version control changes) on any of the other commits. I'm free to fix the conflicts in any order I want, or fix some of them now and worry about the others later, which is much more intuitive to me than using `rerere` to achieve something similar with git directly. I could even imagine a scenario where I might want to push up conflicts that come from attempting to merge my own changes with ones made in parallel from someone else so that they could resolve some of them if I wasn't confident in my understanding of the changes they made, although this isn't something that I've run into yet.
A lot of this hinges on the ways I personally use git; I tend to commit often and not worry about making sure the history is clean or the commit messages are perfect until I actually want to merge them, and I absolutely loathe merge commits, so this ends up meaning I rebase a _lot_. The benefits I mentioned probably wouldn't seem very significant if you don't work on shared codebases often or if you use git in a way that you rarely rebase, but because these feature solve concrete annoyances I'd run into quite often with git, the quality of life improvement feels massive to me.
I can second this opinion. The moment I read "something that beats the git cli hands down" I command-F searched for "hands down" to find this comment or make it myself.
Thirded. I relegated jj-related articles to /dev/null for a long time having believed nothing was likely to supplant git. Then… wow, actually almost exactly a year ago something moved me to read the `jj init` post here. I read it, it was intriguing, I figured I'd give it a try later that week.
I wasn't hopeful. I have a lot of git's working model in my head. Replacing it was going to be hard but hey, might as well kick the tires.
I was productive that day. I knew enough to completely eliminate git from my workflow two days later. I have never looked back, and now I come to sing its praises every time an article is posted. It's immensely fun having seen the proportion of commenters in these threads start tilting sharply in the direction of more and more of HN having used it and loving it.
> I'm 100% on the path of least resistance when it comes to tool adoption.
Different folks will have different preferences when it comes to adopting new tools. Some like "tried and true", some want to experiment and see what's out there.
I (an avid `jj` user) like to think I want some pragmatic blend: I want tools that help me get my job done, and otherwise get out of the way. So if I think there's room for improvement in my workflows (in this case, managing 10-20 ongoing changes at a given time across 5-6 projects), I'll experiment with new tools that can help reduce the friction for me.
Like you said, there's functionally nothing `jj` can do that `git` can't, Jujutsu literally uses git as the default backend. For me, the power of Jujutsu is the massively reduced cognitive overhead of using it. My thoughts more directly translate to `jj` commands and I rarely have to think about it, even with complex stacks of changes.
It solves two problems. First is having a batter UI, git is well known to have a bad UI and be hard to teach. But you’re right there aren’t new capabilities.
Secondly, and more importantly, is that you can back it on to different storage mechanisms. Companies with large monotypes are often not using git (Google, Facebook,…), or are using highly specialised git (e.g. Microsoft). JJ is not just got compatible, git is a pluggable storage backend.
I mostly use JJ backing on to Piper, and the integration is excellent. I’ve also used it backing on to git. I can transfer almost all my knowledge and muscle memory between these two places.
Stacked PRs with multi-branch rebases are effortless. Conflicts are actual things in the history that you can come back to later. Everything is automatically committed, so I don't lose work from a bad reset/stash pop.
Maybe these don't help you with your workflow. But in my case these solve the biggest problems I had with git while still being fully compatible.
I personally switched over in December. For me it solves a few problem in an elegant way:
1. No branches. Instead of having tunnel vision on a single branch, you can easily hop around the tree, creating revisions and switching context without having to mess about stashing files and then remembering which branch and version each stash is for. The fact that your changes are automatically added to a revision make this very easy. You can literally drop what you're doing, `jj edit` or `jj new` a different commit to switch over to working on that stuff, whether it's on a Git branch or not.
For example, you could be working on a feature 'A', push your PR and then start work on feature 'B', only to find your pipeline has failed thereafter. You can then `jj new` a commit off your old feature commit, create a fix and push it (or even `jj squash` it first) and then `jj edit` back over to what you were doing on feature 'B' with no fiddly stashes.
2. Much simpler rebasing commands. For those of us who like to rewrite history to make PRs easier to comprehend for reviewers, and for general rebasing when your target branch has changes, I find the `jj rebase` much saner than Git. It's very easy to rebase a set of commits or move a single commit about in history.
`jj squash` is also great for fixing up earlier commits. You can `jj new` a commit off an existing commit, make a fix or change and then `jj squash` it into the previous one without a fiddly `git rebase -i HEAD~2`.
3. Automatically rebasing of descendents. If I edit a commit in the history, all of the descendents are automatically rebased with this change. So if I realise I've made a mistake in commit `aaa` and edit that commit, `bbb` and `ccc` that are derived from it will automatically incorporate this change, with commits being market conflicted if this can't be done.
4. Conflict handling. Any conflicts are recorded against
commits and doesn't prevent operations from working. So you don't have to immediately drop everything and work interactively through a set of conflicts. Combine that with the automatic rebasing, above, and your resolutions propagate through the descendents similar to using git rerere.
So those, for me, are the killer features.
On the downsides:
1. HTTPS Git repository handling is poor. There is no vault integration, at least on Mac, so I have to enter my username and password every time. This is not a problem for SSH, but my company prohibits SSH, so it's a pain. ** see reply below, credential helper now works **
2. Git fetches seem slower for large changes than using Git fetch directly, and I've had the tool timeout on repositories with large files. Combined with the above issue I tend to now `git fetch` rather than ever `jj git fetch`, avoiding the two problems, and just push with `jj`.
> 1. HTTPS Git repository handling is poor. […] 2. Git fetches seem slower for large changes than using Git fetch directly
JJ used to use libgit2 for fetches, but it now can shell out to the git binary instead: https://github.com/jj-vcs/jj/pull/5228 (which will be the default in the future)
Yes, so far these jj blog posts do not sell it well at all.
Not to mention the rainbow colors are a bit of a turnoff. I like a little color here and there, but not ransom-note style. Monochrome effects are available folks.
Maybe the blog posts don't sell it well, but I find it pretty telling that bordering on zero people ever enter the comment section for Jujutsu posts to complain about a bad experience they had. Just dozens upon dozens of people singing its praises.
Think about literally other technology post on this site. Nothing is universally loved.
That's the problem, no one can cogently/concisely explain why. I don't love git but have sanded its rough edges already. Gitlab did the rest.
I recommend this Spolsky classic on how to convince one to try a new VCS: https://hginit.github.io/ Doesn't have to be this long but note his writing style.
There are literally dozens of examples of comments in this thread doing exactly that. Perhaps those explanations don't resonate with you and that's fine.
You're still missing the why and more specifically how. It's not enough to tell a story full of vague assertions, you have lead the reader through what amounts to a tutorial.
There are plenty of specific, pointed assertions being made. Maybe they don’t resonate with you. Again, that’s fine. You are not owed an explanation that meets your personal set of criteria.
I've linked directly to the Outline/TOC in order to provide a more immediate overview of the post's content but there's also a chunk of more "philosophical" introductory text before the Outline: https://v5.chriskrycho.com/essays/jj-init/
The introductory text has parallels with the "Subversion Re-education" section of Spolsky's document--including the apparently mandatory (though stated in more reserved terms) reference to the effect the incumbent VCS has on one's brain: "just how weirdly Git has wired your brain". :D
As to the "why", to quote from the intro:
----
Jujutsu is two things:
(1) It is a new front-end to Git. This is by far the less interesting of the two things, but in practice it is a substantial part of the experience of using the tool today. [...]
(2) It is a new design for distributed version control. This is by far the more interesting part. In particular, [...] a few key concepts [...]:
(2.1) Changes are distinct from revisions: [...]
(2.2) Conflicts are first-class items: [...]
(2.3) The user interface is not only reasonable but actually really good: an idea borrowed from... literally every VCS other than Git.
----
As someone who reluctantly stopped using Mercurial primarily due to the friction around using hg-git to interoperate with GitHub, I think Jujutsu's approach of focusing initially on developing atop the "git backend" for interoperability is both wise & IMO pretty much a requirement for any project hoping to become the next industry standard VCS that everyone complains about. :D
Having said that, while I'm positive about the project's approach & potential, have read multiple Jujutsu articles, docs & even downloaded a binary, I'm yet to actually use it.
By now the main reason I've been less inclined to prioritize trying JuJutsu out is the project's mandatory CLA requirement for contributions: CLAs are anti-developer & an abuse of the power differential between individual developers and corporate entities.
I'm sure they'll realise the error of their ways eventually. :)
And, yes, perhaps I'm tilting at windmills--but that's probably also why I stuck with Mercurial for so long and why I'm even considering/hold out hope for a git replacement... :D
The CLA may not be as bad as you think. There are different kinds of CLAs. This one does not give away your copyright at least. See https://github.com/jj-vcs/jj/discussions/4849 for discussion.
I hope the project sees continued success as another step into a world where we can acknowledge that developers are human; and, that--rather than just telling those humans they should "git gud"--we recognize that it's okay to tell our tools to "git gud" and then support the humans who contribute to making that happen.
(And, for those who fear such a world will be lacking in developers who "gut gid", remember: nobody is stopping you from still helping those humans "git gud", it just might require you to "git gud" at "gudding gittering".)
(And, yes, one day I also hope that world also doesn't require a signed CLA. :) )
----
> The CLA may not be as bad as you think.
Unfortunately it is at least as bad as I think. :)
While writing my previous comment I did consider going into more detail around the CLA but didn't--in part because succinctness made the CLA remark more impactful; in part because my comment was lengthy already; in part because I was tired of typing; and, probably, on reflection, in part as bait. :)
For context around the sentiment of this reply: I do appreciate you taking the time to reply to my previous comment & the effort you've put into Jujutsu; I support the Jujutsu project's goal; and, I would like to see it succeed. If I didn't view the project positively I wouldn't take the time to reply.
I was already aware the CLA didn't include copyright transfer and had checked the current information in the README to verify the current status hadn't changed before I wrote my previous comment. I had a recollection there had been previous CLA discussion but didn't go looking for it.
I've now read the discussion you linked as well as (some or all) of the other discussions/issues linked from it.
I'm glad to see others who view the Jujutsu project & its potential in a positive light have raised their concerns around the CLA and the CLA's negative impact on the project--even if I might wish some had expressed themselves... differently. :)
[Aside: I would have added (well, some of :) ) this comment to the GH discussion directly but MFA-related reasons preclude that currently. Feel free to quote from this comment over there if that's useful.]
----
While I'm glad the corporate "fad" of adding CLA requirements to projects has died down in comparison to a few years ago, one of my concerns has always been that the "costs" associated with requiring a CLA often have very poor visibility. Most people who have objections to a CLA requirement simply don't interact with projects that have them.
This obviously makes it difficult for project maintainers to argue for removal of CLA requirements because they can't point to the negative impacts that exist.
That's one reason why I specifically mentioned the CLA in my previous comment, so that if someone was wanting to argue for removal of a CLA requirement within a company then it would at least provide one external data point in support of the argument (as small as it might be) to which they could point.
----
While other people may have different reasons, for context, my primary objections to the requirement for a CLA boil down to: (i) legal liability; and, (ii) power dynamics.
(i) Based on my reading of the CLA[0][1] the motivation for Google to require contributors to sign seems to be a desire to move legal liability from Google onto the contributor.
By signing the CLA the contributor appears to accept a burden in perpetuity that: impacts every interaction[2] with an unbounded number of entities in an unbounded set of situations (see 1.); makes multiple representations about the licenses granted (see 2. & 3.) that presumably incur legal liability if they not are not accurate (see 4. & 5.); requires communication with Google in a manner ("notify") that is undefined in the document, about an almost unbounded set of items ("any facts or circumstances of which you become aware", "inaccurate in any respect"), again, in perpetuity (see 8.).
Now, at this point, the typical 10x legal scholar HN reader might be thinking, "Typical uninformed software developer who thinks law operates like code, clearly the CLA doesn't mean that...". Which brings me to...
(ii) From my perspective, in a situation where one party is requesting another party to sign a legally binding document (with the assumption their goal is not to take advantage of the second party[3][4]), they have at minimum a moral obligation to remind the second party that the document is legally binding, that signing it brings obligations, and that the second party should seek legal advice from an attorney they have a client-attorney relationship with and who is acting on their behalf to be informed about the potential cost(s) and/or benefit(s) associated with signing the document.
Especially if there is a significant power differential[5] between the two parties.
Particularly when the larger entity is making the request of an individual who is giving them a gift of value.
Even more so when the larger entity is specifically making the claim to the smaller party giving them a gift of value, that the document "is for your protection as a Contributor"[9][10]!
My current theory, in absence of other information, is that one day there was a conversation along the lines of:
Lawyer: "Nice beanie. BTW accepting free labour from random people on the internet puts the company at risk of being sued if it turns out the output of the free labour actually belongs to the labourer's employer or infringes a patent or [some other legal thing the author of this comment don't know about]."
Google Exec: "That sounds double-plus bad and/or [some other internal Google slang phrase with which the author of this comment is unfamiliar due to being a sub-100x Developer]."
Lawyer: "I can confirm that assessment of the situation."
Google Exec: "What ever can we do to avoid or minimise this potential liability?"
Lawyer: "Well, acting on the advice of my attorney, I am permitted to suggest that requiring internet randos--who are presumably well informed about legal matters and will definitely seek legal advice before signing any legally binding agreement[12] easily distinguishable in significance from the TOS which I am legally bound to say I am confident they also read & understand in its entirety before signifying their acceptance--"
Google Exec: "Dude, take a breath! You're not a HN comment author who thinks stereotyping lawyers & executives is funny, endearing & sure to bolster support for his quixotic cause."
Lawyer: "--to sign a document known as a Contributor License Agreement that will mean this company can say Hey, we're victims here too if some company tries to sue us because it turns out the contributor did not actually have the right to give us the output of their free labour."
Google Exec: "What possible negative impact might a CLA have on a project? Won't the valued contributors to projects under the Google GitHub organisation object to signing over their copyright to a company that may be worth over $USD2.20 one day?"
CFO: "Trillion! I keep telling you it's $USD2.20 Trillion!"
Lawyer: "Well, (a) I'm not a monster! There's no need to require copyright assignment to this for-profit corporate entity. And, also (b) I'm a lawyer able to advise on matters of law and not a project maintainer or community manager, I don't know how such valued contributors think and what they themselves value. I would recommend you consult experts in such matters, such as esteemed project maintainers or program managers who interact with the community and can advise you of community sentiment about such matters."
Google Exec: "That sounds like excellent advice, I will do that."
Google Exec: "Unrelated but while I've got you here, I'm interested in some advice on another matter, you know how we've never leaned into the whole 'Google is always killing things' thing...
As it happens, I have actually submitted PRs to projects with CLA "requirements" before--if I recall correctly, the first time was by accident because I didn't realise there was a CLA requirement (projects that don't clearly state that upfront... have room for improvement).
Subsequent such occurrences were intentional.
And I've had a non-zero number of the PRs merged.
Despite stating that I did not intend to sign the CLA.
Because, guess what, there's no legal requirement for a CLA in order to accept a one word comment or documentation fix--it wouldn't even qualify for copyright protection. And, BTW, I'm definitely still not a lawyer.
Why did I intentionally submit a PR to a project I knew required a CLA? Just to be an asshole? Well, I'd prefer "smart-arse", but either way, no.
The purpose was to actually provide visibility into the cost of requiring a CLA.
Instead of letting the cost stay invisible and thus continuing to ensure a lack of evidence to which project maintainers might point as the motivation for change.
A one word doc fix? Who cares, that's practically worthless, right? Well, at least one project decided it was worth at least enough to "break the rules" and merge it without a CLA...
But that's not really the point because it's not just one word fixes that projects are missing out on because of CLA requirements. Its all the multi-line PRs fixing bugs, adding features, fixing security vulnerabilities, reverting tabs-to-spaces format changes, reverting spaces-to-tabs format changes, and reverting reverting spaces-to-tabs format changes--all those PRs that never get written so the cost is entirely invisible.
----
But what kind of person would care enough about CLA requirements to not want to sign one and yet still put effort into submitting a multi-line PR significant enough for a project to want while knowing it would unlikely to ever be accepted?
*cough*
No idea, I've never followed through on that particular action. :)
(In part because projects started either ditching CLA requirements entirely or changing them to a DCO requirement which at least in comparison I have less of an issue with for the moment.)
But how many people submitting useful PRs but not signing CLAs would it take before a project might start asking (themselves or whoever might be imposing the requirement): "Why are we requiring a signed CLA when it has this cost?".
It also turns out there's actually another potentially really interesting nuance of CLAs that I didn't consider until after the fad died down which I've not seen mentioned.
----
The negative impact of a PR without a signed CLA primarily affects the organisation requiring the CLA.
It's only the organisation requiring the CLA who cannot (by their own rules) benefit from a PR without a signed CLA. Any other member of the project can freely merge the PR into their own (or community) fork under the terms of the license by which it was contributed.
Now, some might object to contributions being "weaponized" in this manner but:
(a) Would you still complain if an AI instead of a human came up with the idea to "weaponize" in this manner? :D
(b) What other leverage do communities have against companies that some might describe as "holding community projects hostage"; or, at a minimum damaging the project, with a CLA requirement?
(c) Oh, that's not a weaponized contribution, this is a weaponized contribution: once a PR has been written to, say, add a feature to a project, a contribution that is, say, of sufficient size & creativity to be eligible for copyright protection... Now, if that were to happen...
BTW did I mention that I'm definitely not a lawyer? If I haven't previously, well, to remove any potential doubt: I'm not a lawyer. Just one of those developers who apparently seem to think the law is like code[13].
Anyway, the thought that occurred to me one day was: if there was a PR of contributed, licensed, copyrighted code for a feature but no signed CLA... could, that, perhaps, maybe, poison the well in relation to anyone else developing an alternative PR for the same feature but with a signed CLA?
And, if so, would that create some potential legal liability, for, say, a company like Google, if the project were to, say, merge such an alternate PR?
Because, like, wouldn't they have to be able to prove that the alternate PR isn't actually based on the PR without a signed CLA in order to avoid potential liability for, I dunno, copyright infringement or something?
Now, I may have mentioned this before but I'm not a lawyer.
With that in mind, the answer is: No!
Potential liability? Now, now, there's no need to be silly, Google has a signed CLA stating that the contributor totally represented that they could grant whatever the CLA grants. No legal liability for them, woo!
Well, unless it was an employee who wrote the alternate PR, I guess? But I assume there's processes for that...
But it turns out I'm the silly one because there actually seems to be a straight-forward "solution" which literally only just occurred to me as I was writing this up--and it seemingly doesn't require anything other than lawyering silliness!
Let me quote here Point 7 (see 7.) of the "Google Individual Contributor License Agreement" for the purposes of review & criticism in a manner hopefully compliant with the concept of "Fair Use" in some jurisdiction:
"7. Should You wish to submit work that is not Your original creation, You may submit it to Google separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as 'Submitted on behalf of a third-party: [named here]'."
So, umm, that's certainly... a thing.
BRB, off to submit a new "Audio GIF"-based backend for Jujutsu without signing a CLA!
(You know, so someone who has signed a CLA can seemingly totally submit it in a manner consistent with the project CLA as long as they don't misrepresent my code's source and mention any "Audio GIF"-related patents. GIF-related patents? LOL Zero Worries there! As if. My butt's patented[15].)
----[epilogue]---
There were a couple of other things I'd thought to mention but I'm going to leave things here---particularly given Point 7.
And, as some additional context, in case anyone happens to be interested: Yes, this is a ridiculously long comment containing a lot of content seemingly written to primarily amuse the author. Well, yes, that's an accurate observation. I have attempted to at least make its content semi-navigable by section out of respect for the time of those who wish to glean its content without its... other content.
Maybe one day I'll... write more about the context of that. :)
[Update: Okay, admittedly, that was way longer than even I had realised. :D ]
[1] A document which I note has no associated date or revision information.
[2] But at least now I know why I kept seeing "Not a Contribution." in issue comments on GH, I guess.
[3] Or, you know, to at least not to be evi... oh.
[4] But, in actuality, even then.
[5] A situation I would posit exists between a corporate entity with a market cap of over $USD2.20[6] and over 80%[7] of typical individual contributors to FLOSS projects.
[6] Oh! Actually over $USD2.20 Trillion? Assuming my source is accurate[6.5].
[6.5] I'd encourage everyone to: independently verify my claims; consult your financial advisor; seek legal advice from your attorney licensed to operate in relevant jurisdictions; and, ask your doctor if any treatment plan, financial statement, legal claim, or, punctuation contained in this comment is accurate and/or right for you.
[7] Maybe even 99%[8].
[8] But as a sub-100x Developer I'm not privy to details of TC packages at the higher end of the SV scale, so might even be closer to 99.5% of typical individual contributors but wouldn't want to overstate my claims.
[9] A statement I'll readily admit I was extremely surprised to see in the Google CLA. You know, given I would've thought such a claim would leave the company open to some sort of legal liability or risk of agreement invalidation if it turned out the document didn't fully and completely protect a contributor (& I assume their heirs?) in every situation & jurisdiction in perpetuity. But as I may have mentioned I'm not a lawyer and definitely not qualified or licensed to practice law in whatever jurisdiction applies in this situation, so... *shrug*
[10] The fact the CLA doesn't seem to state anywhere from what nor how the contributor is protected; nor, for that matter, from what, if anything, they will not be protected[11]. Which to me seems to make it difficult for any contributor (or their legal counsel) to evaluate whether signing the agreement is a good idea.
[11] The best I could come up with is maybe Google's reasoning is that by "requiring" contributors to interact with their employer they will be "protected" from unintentionally contributing something to which only their employer actually has the rights. But that seems pretty weak. And, as I say, I can only make a guess because Google doesn't actually specify any of it anywhere.
[12] Chorus: sotto voce "Because let's be honest here, is there even a single person at Google who is prepared to swear under oath that there is data to support the idea that there is even a simple majority of people who have signed the CLA that read it, understood it, obtained legal advice about it and are thus in a position to provide 'informed consent' by even the low standard of the law let alone morality?"
[13] Well, you know, clearly with the exception of global copyright infringement (oh, sorry, "training material hoovering") without such minimal courtesy as attribution because while apparently individuals have to abide by copyright law and wait until material enters the public domain after a term of close enough to one hundred years or more after publishing--a term demanded by multi-billion dollar corporations--apparently other multi-billion-dollar are too important to have to wait or brib... lobby for law change or license material or *gasp* pay for the creation of new works.
I'm not that naive and stupid even as a sub-100x Developer.
[14] [redacted]
[15] This joke is patented.
[16] Wait, what if I actually am a lawyer, licensed to practice law in some relevant jurisdiction? That seems like it would be super awkward.
That’s a problem created by GitHub or people unable to think outside of the GitHub model. It would make more sense to solve that problem through a review tool.
For what it’s worth from what I’ve read about JJ: it’s a better VCS frontend overall.
There are two distinct but related issues here: GitHub's terrible support for stacked PRs, and Git's `rebase -i` user interface to manage them which is quite bad. Jujutsu fixes the latter.
I maintain a fork of a tool called `spr` which comes as close to fixing the former as GH allows. It has a number of limitations, though. https://github.com/sunshowers/spr
I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git cli hands down. I'm 100% on the path of least resistance when it comes to tool adoption.