I look forward to read your beautiful, thoughtful, well-commented commit history. No more "Merge branch 'asdfasjkfdlas/alkdjf' into sdkjfls-final" ;-) .
HaraldvonBlauzahn
- jj is overeager about adding stuff to ðe repos; it's by design.
One just needs to learn how to un-track stuff, by adding the missing .gitignore entry, issuing the "jj file untrack" ..." command, and removing the file.
The big advantage is the simplification which becomes possible by this: no staging area, no git add, no stash save, stash pop, stash apply, and so on. No git amend, fixups, reset soft/hard/ mixed,...
And the overall complexity saving of jujutsu is enormous: two of the man pages on the more complex git commands are already larger and more complicated than all of the jujutsu command line reference (link)- which is pretty complete! And Steve Klabnik's jujutsu tutorial is about a tenth of the length of Beejs brilliant Guide on git. And with Klabnik's Introduction, you can already do more (for example complex rebase operations, like rebasing multiple branches at once).
But, did you try it? Myself, I was comfortable with working with it after one hour or two - after working with git for 18 or 19 years, and often being the first git user in my organization.
The entire point of branches is to have a name that has meaning to me that I can use to refer to work I'm doing.
You already have a name for every change/commit: The first line of the commit message, which you can write when you start work on it.
Branch names in git are temporary: When a branch is merged, its name disappaers.
This is... unforgivably obnoxious.
Well, if you really don't like it after giving it consideration - use git. Nobody forces you to use jujutsu.
Yeah. It can be used e.g. instead of command-line git commands, or also be intermixed with them. Pushing a branch to a git server works as normal "git push" (needed in older versions with complex vpn/ssh configurations).
Has also still limitations remaining - no git submodule support. But it has work trees.
The mental model is fascinatingly simple. It is: You have a directed acyclical graph (DAG) of "changes", which are often drawn like this.. Then, you have a small set of commands that operate on that graph, e.g. adding changes, fusing two into one or splitting up one into two, adding nodes that have more than one parents, rebasing single nodes or a series of changes. And changing the content of these nodes in the commit graph is almost always done with the normal source code editor - everything one saves becomes already part of the graph when the next jj command is run.
Jujutsu does not use branches much because you are focused on the nodes in the commit graph. And instead of giving every of them manually a name, they are identified with change IDs. Branches are called "bookmarks", they can be attached to a commit graph node, and are used mostly for collaboration.
And when you push that graph of mutable changes to remote, they become a graph of normal commits that should not be changed under normal circumstances (because they are shared history now).
I was surprised by that sentence, too.
But I see from my AI-using coworkers that there are different values in use for "it works".
There are a few aspects that LLMs are just not capable of, and one of them is understanding and observing implicit invariants.
(That's getting to be funny if the tech is used for a while on larger, complex, multi-threaded C++ code bases. Given that C++ appears already less popular with more experienced people than with juniors, I am very doubtful whether C++ will survive that clash.)
Well, if your country is more progressive than the vatican, why isn't it carbon-neutral already?
The problem is not that it is difficult to phase out carbon, the problem is capitalistic greed that corrupts leadership of our entire civilization.
At which point will we start to treat the destruction of our climate and our planet as violence?
It is no secret that git's interface is a bit too complex - even XKCD has made fun of it.
But what is amusing is that people now have a kind of Stockholm Syndrome, and plain refuse to believe there could be something better.
(Perhaps motivated by the long list of half-assed helper interfaces and GUIs which just were hapless trying to hide the sprawling complexity).