18 ms·

Jujutsu: A Git-compatible DVCS that is both simple and powerful

673 points by lemper 3y ago

ctenb 3y ago
Does anyone have experience with large repo's of say, 100 GB? Does jj incur performance penalty's compared to native git?
- arxanas 3y ago
  It depends on whether you're talking about 100 GB repository size or working copy size. - Currently no partial/shallow clones, so you need to materialize the entire repo on disk. - Working copy status can take a while (see https://github.com/martinvonz/jj/issues/1841 https://github.com/martinvonz/jj/issues/1841 for tracking issue). This can be ameliorated at present by configuring Watchman as a filesystem monitor, and work is underway to improve status further. - No support for Git LFS at present (even in colocated repos). When using the Git backend with jj, you would expect the same problems with regards to large file management. - I haven't noticed any particular performance issues when interacting with the object store a large repository. It should be approximately the same as for Git since it uses libgit2 for the Git backend. - Faster for operations that can be done in-memory in jj but only on-disk with Git, such as various rebase operations.
mcqueenjordan 3y ago
Oh wow, this looks really promising. I've been playing with a homegrown centralized VCS client and server project, aimed at basically being the VCS host for monorepos, and this looks like a much better foundation for the VCS layer.
teleforce 3y ago
Jujutsu started as author's personal project and now author's full-time project at Google. It's presented at Git Merge 2022: Jujutsu: A Git-Compatible VCS - Git Merge 2022: Video: https://youtu.be/bx_LGilOuE4 https://youtu.be/bx_LGilOuE4 Slides: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX_L4bQ9NMcYOp1isn17kTC_M/view https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX...
- robertlagrant 3y ago
  > started as author's personal project and now author's full-time project at Google That's got to feel good!
  - jrpelkonen 3y ago
    Absolutely, good for the author. However, given the numerous examples of Google pulling the plug on nonessential projects, I don’t see this as strictly positive development.
    - scq 3y ago
      Well, it is open source, so the author or someone else could always pick it up again as a personal project if that happened.
      - sdesol 3y ago
        Based on this https://devboard.gitsense.com/martinvonz/jj https://devboard.gitsense.com/martinvonz/jj it looks like there are two people working on it full-time, with 7 people contributing at least 500+ lines of code churn and 14 contributing code changes. Overall the project is fairly healthy and there does appear to be enough people engaged with the project that it should continue, should Google pull the plug. Full disclosure: This is my tool
    - collinmanderson 3y ago
      Google should go back to slapping a huge "Beta" label on every single product.
gyulai 3y ago
I had to choose a VCS for a project a year ago. At that point jujutsu looked extremely promising but immature. It's great to see that so much progress has been made. I can't wait to give it another go, the next time I get to choose a VCS for something. Innovation in this space is desperately needed.
zelphirkalt 3y ago
I would say "What a weird name for a VCS. Whether that will work ...", but then I have to remind myself of the dictionary meaning of "git". So who knows. Maybe we will be adopting all kinds of martial arts terminology. For example: "I use Karate to manage my code. I divide everything using chops. When a kata is done, ..."
- dagurp 3y ago
  It's a horrible name to pronounce for many non-English speakers.
  - hosh 3y ago
    Ironic because it’s a Japanese name, not English. According to the readme, “jj” was chosen because it was easy to type, and a name was found to fit that.
    - avgcorrection 3y ago
      [flagged]
  - apeescape 3y ago
    Did you know that the English way to pronounce "jujutsu" isn't how the Japanese pronounce it? The Japanese way to pronounce it could actually be a lot easier for many non-English speakers (I'd anyway argue it's a common enough word that people are familiar enough with it to pronounce it in a way that's comfortable to them).
    - nordsieck 3y ago
      > Did you know that the English way to pronounce "jujutsu" isn't how the Japanese pronounce it? Really? The wiki audio sample[1] seems fairly close to how people in the US pronounce the word, just with a more emphasized first syllable. --- 1. https://upload.wikimedia.org/wikipedia/commons/f/f1/Ja-Jujutsu.oga https://upload.wikimedia.org/wikipedia/commons/f/f1/Ja-Jujut...
seertaak 3y ago
I'm definitely going to try this, looks really sweet.
shandor 3y ago
The automatic rebase and jj diffedit sound very nice addition to some of my most-used git workflows. Looks very interesting, will definitely have to give this a deeper try.
mcluck 3y ago
Looks really cool! One thing I'm not clear on from the docs: does it support ignoring changes to some files for "real" commits? For example, a repo at work has a file used for mocking up feature flags. The file is tracked but it's encouraged to edit it when testing things, just don't commit your changes. If I'm not mistaken, I'd have to remember to undo changes to that file before "describing" the commit. Is that right?
- ilyagr 3y ago
  The commit will indeed be created immediately, there's no way to prevent that except for .gitignore I'm aware of. Until you run `jj describe`, it won't have a description. However, if you don't manually put a branch on it, it'll never get pushed and will stay on your machine only. You can sit on this personal commit and rebase it on top of any other commit to move around the repo, again and again if you like.
- psd1 3y ago
  I know the nuisance of having to tiptoe around files you don't want to add to history. In case it helps your use case: git update-index --assume-unchanged <file> git update-index --no-assume-unchanged <file> This would ignore changes while you're testing - but you have to remember to turn it off or, iiuc, you won't pull intentional changes either. You might find hooks useful too. Not to assume your knowledge, these are shell scripts placed in .git/hooks that are invoked, e.g., before commit or before push. You could have it parse git status, detect changes to <file>, prompt for confirmation if changed and remove from working set if the change is unintentional.
  - mcluck 3y ago
    I never knew about the `update-index` command. That's going to save me a lot of time. Thanks!
geenat 3y ago
Explain how does it handle large binary files? (the UX around this is the shortcoming of all current DVCS..)
- ozkatz 3y ago
  Might want to look at purpose built tools for that such as lakeFS (https://github.com/treeverse/lakeFS/ https://github.com/treeverse/lakeFS/) * Disclaimer: I'm one of the creators/maintainers of the project.
- dahhowl 3y ago
  README says that the git backend is the recommended backend, as the "native" one has no additional features, so I imagine: it handles them the same as git (ie. they are just objects in the .git repo data, and each time you change them you add a new one, and they are poorly compressible and optimizable) -- which is, I imagine, the problem you're referring to.
  - rkangel 3y ago
    It won't be completely the same as git, because the client fetches stuff more lazily (according to the linked presentation). So the backend will still fill up with stuff and need lots of storage, but the clients then won't necessarily slow down in the same way. That said, any git users will still get slowed down - only jj users would see the benefit. Git does have better features these days for shallow clones though and even git is on the way to killing off the need for LFS.
- Beldin 3y ago
  Now I'm curious: how would you want a DVCS to handle large binaries?
  - Ygg2 3y ago
    Partial checkout/Shallow first checkout. JJ doesn't seem to do that though, right?
  - chaxor 3y ago
gautamcgoel 3y ago
I am certainly no expert in version control systems, but I've gotta say that it's really wonderful to see a project that builds on the algorithmic and cultural successes of Git but with a simplified and modernized approach. The reason that Git took over the open-source world is two-fold: first, it was adopted by Linux, which ended up being the most influential OSS project of all time. Second, the Git model, which is distributed and egalitarian at its core, is a natural model for a fast-paced, globally distributed community of developers. These are both reasons to appreciate Git, but they do not imply that Git is the final word in version control. I'm excited to see innovation in this space!
- robertlagrant 3y ago
  > which is distributed and egalitarian at its core, is a better model for a fast-paced, globally distributed community of developers than previous monorepo systems like Mercurial I'm a bit confused by this. I don't think that's what monorepo means, is it? Monorepo is what you choose to put in a repo? And I thought Mercurial was extremely similar to Git as it's also a DVCS?
  - pmezard 3y ago
    Git and Mercurial are fairly similar, at least compared to what OP is apparently hinting at. Different tech and different internal architectures, but both of them are DVCS offering roughly equivalent workflows.
  - brmgb 3y ago
    It is. The OP is wrong, probably because he has never used Mercurial, which wouldn’t be that surprising given it doesn’t have a lot of users outside of the few remaining companies still using it.
    - robertlagrant 3y ago
      I've never used it, but I have read hg.init[0]! [0] https://hginit.com https://hginit.com
  - 3y ago
pxc 3y ago
This Git-compatibility-first approach makes Jujutsu seem like a stronger contender to replace Git than I've seen so far. I'm curious about its management of conflicts. I know that pmeunier has taken a lot of care to formally work out a theory of patches to drive Pijul, and that unsound or problematic notions of patches/conflicts can lead to serious problems— they say that's what led to all the performance problems with Darcs, right? I'd love if the comparison page on the repo wiki gave a little more detail than that Pijul's handling of conflicts seems 'similar'.
- arxanas 3y ago
  There is a little more detail here: https://github.com/martinvonz/jj/blob/main/docs/technical/conflicts.md https://github.com/martinvonz/jj/blob/main/docs/technical/co... Storing the conflicts symbolically in this way lets you reproduce the conflicts later and even auto-resolve certain conflicts, but it doesn't address resolving the actual contents of conflicts. You could probably use Pijul as a jj backend and get the best of both worlds (if someone were to implement it).
vesinisa 3y ago
This looks promising. One question I had after reading about its git compatibility is that they seem mostly focused on the use case where a Jujutsu user accesses a git repository (hosted by e.g. GitHub) with jj. But does it support the converse way of working, i.e. accessing a native Jujutsu repository with git? I ask this because most developers are already quite familiar with the git CLI so in production use one would probably see developers co-working with jj and git in the same codebase. Or would the realistic production scenario be always using git (as opposed to native Jujutsu database) as the backing storage to allow accessing both with git and jj CLIs?
- UzEE 3y ago
  I would assume there would always be the expectation that you either use Jujitsu as a frontend to a git repo, or have a complete Jujitsu based remotes. If you're going to work on and contribute to a project that is already using Jujitsu, it is reasonable to expect that you'd adapt your workflow to the project itself and not the other way around.
  - vesinisa 3y ago
    Thanks, it makes sense. I don't understand why this was downvoted.
- me-vs-cat 3y ago
  The README's footnote: At this time, there's practically no reason to use the native backend. The backend exists mainly to make sure that it's possible to eventually add functionality that cannot easily be added to the Git backend.
  - sedatk 3y ago
    That footnote has a “won’t be big and professional like GNU” feeling to it.
toomim 3y ago
> The working copy is automatically committed. Thank goodness. This has been needed for a long time. Props to the author Martin for investing himself in creating elegance!
ocharles 3y ago
Nice to see this posted here. I switched over to it about 2-3 weeks ago, and I haven't looked back. It took a lot of mental rewiring, but I really enjoy the workflow `jj` provides. There's no longer a time to think about what's being committed, because all file changes automatically amend the working copy commit. Of course, sometimes you don't want this, so you have things like the ability to split a commit into two, moving commits, etc. But having _everything_ operate on commits is really nice! Other niceities that I like: - `jj log` is awesome for getting an overview of all your branches. If, like me, you have a lot of work in progress at once, this provides a great map - Conflict resolution is really cool, as you can partially resolve conflicts, and then switch branches. Conflicts are also tracked specially, but I haven't done too much with this yet. - The abbreviated changeset ids are really handy. I often will just `jj log` (or in my case just `jj` as that's the default), notice a changeset I want to rebase, then run `jj rebase -s qr -d master`. `qr` here is an abbreviated changeset id for a branch/commit, and usually much quicker than typing the branch name out! This will probably change when clap gets updated to support dynamic tab-completion though.
- TylerE 3y ago
  What happens if you accidentally save a file with some sort of secret that gets sucked in?
  - Certhas 3y ago
    Isn't the idea that you continue editing the working copy commit until you actually commit it? Also from the documentation: https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md https://github.com/martinvonz/jj/blob/main/docs/git-comparis... "As a Git power-user, you may think that you need the power of the index to commit only part of the working copy. However, Jujutsu provides commands for more directly achieving most use cases you're used to using Git's index for. For example, to create a commit from part of the changes in the working copy, you might be used to using git add -p; git commit. With Jujutsu, you'd instead use jj split to split the working-copy commit into two commits. To add more changes into the parent commit, which you might normally use git add -p; git commit --amend for, you can instead use jj squash -i to choose which changes to move into the parent commit."
roytam87 3y ago
... so a Jujutsu Kaisen begins if getting a commit conflict?
- KingMob 3y ago
  Really sad jj wasn't short for "JoJo's Bazaar Gitventure".
baq 3y ago
Related DVCS: https://pijul.org/ https://pijul.org/ I need to try it out at $WORK since constant rebasing on a busy repo with a hundred or so committers is not fun.
- goku12 3y ago
  Pijul needs a 1.0 release if it wants wide adoption. I don't understand why they wait. Meanwhile, if rebasing on git is an issue, you should probably try stacked-git (https://stacked-git.github.io/ https://stacked-git.github.io/). It manages commits as a stack of patches - like quilt, but on top of git.
  - toastal 3y ago
    git-branchless also fits in the same vein as stacked-git with everyone’s favorite commands like `record`, `unrecord`, & `smartlog`. That said, I’ve been using darcs this past month & the performance issue seem overblown (/ largely fixed, tho not fully addressed) while the stability & usability are there. Email support is a bonus.
awestroke 3y ago
"working copy is automatically committed" seems like a good idea at first glance, but there are many situations where this is not a good idea: - when new artefact files are added and you have not yet added them to .gitignore, they'll be automatically committed - when you have added ignored files in one branch and switch to another branch, the files will still be in your working copy but not listed in your .gitignore file, and would then be automatically committed - staging only some files and comitting is much easier than splitting a commit after the fact
- Certhas 3y ago
  I don't see how these things are an issue in jjs design, nor do I see how staging some files is easier than splitting a commit after the fact... Check out the documentation, many of the cases you are concerned about are explicitly mentioned: https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md https://github.com/martinvonz/jj/blob/main/docs/git-comparis...
  - tom-dixon 3y ago
    Constantly having to split after the auto-commits feels like I have to keep fighting this automated commit system. It's a bit like the autosave feature of text editors, which some people find useful, but I never felt like it's needed. A big downside I can see is that sensitive information might end up in the repo forever because I forgot to revert the auto commit.
    - sanderjd 3y ago
      I always end up reading through my commit diffs while committing and then maybe like a third of the time I edit something about them. So for me this seems like it could be a natural acknowledgement of that; just make that editing after the fact be the primary / only workflow. Haven't used this yet so no idea if it's actually great or terrible, but I like to see ingrained conventional wisdom challenged like this. We're always in some local maximum, so I think it's often interesting to be pushed in some new direction on the gradient.
    - 3y ago
Certhas 3y ago
This looks incredibly good to me. The working copy as "commit being worked on right now" is a much simpler data structure than the "working copy + stash + staging area" of git. I really hope this succeeds... VSC support would be a great start...
jimsimmons 3y ago
This project is a great example of subliminal marketing. It is less apparent now but still, the repeated flex of “Google”, 20% project etc when no typical reader would assume them is classic corporate charlatanry. Shame because I like the project otherwise
- psd1 3y ago
  It may be a calculated move. But, more charitably, perhaps it is simply unpolished communication.
contctlink 3y ago
I thought it was about UFC for a sec :)
anentropic 3y ago
I was expecting to be meh, but by halfway through the readme I was thinking "this actually sounds great!"
- frizlab 3y ago
  I was (and still am) meh. YMMV I guess.
e12e 3y ago
Looks interesting. Unfortunately doesn't support signing commits - apparently it's possible via "jj export" and using classical git: https://github.com/martinvonz/jj/issues/58#issuecomment-1247940400 https://github.com/martinvonz/jj/issues/58#issuecomment-1247...
- rslabbert 3y ago
  The plan for how the add signed commits is there, and the work isn't that hard (especially as gitoxide continues to add functionality), it just has to be pushed over the line and I've been a bit slack on getting that going. There's definitely nothing foundational blocking it though and it will happen one day if you'd like to give it a go in the meantime.
k__ 3y ago
Do I understand this correctly? This is some kind of background process that automatically commits any changes you make. You can use the CLI to check what it did and if you want to modify the auto commits.
- OJFord 3y ago
  No daemon, it happens 'whenever you run a command'. > Commands snapshot the working copy before they start, then the update the repo, and then the working copy is updated (if the working-copy commit was modified). Almost all commands (even checkout!) operate on the commits in the repo, leaving the common functionality of snapshotting and updating of the working copy to centralized code.
  - systems 3y ago
    so commit is a side effect, not an explicit action weird choice, isnt explicit always better than implicit
psd1 3y ago
The tool looks great; I have a hurdle to overcome with the name. I'm long accustomed to spelling it, in English, as Jujitsu. I've also seen Jiu-jitsu. "jutsu" is much less common, IME. Is there such thing as canonical Romanisation of Nipponese? I can deal with a project being "wrong" better than not knowing which of us is wrong.
- brendev 3y ago
  I think your question is getting into the field of martial arts lineage. People might have their own narratives/ mythologies around this, but here's the most neutral way I can explain it: As techniques and styles evolve over the years, people come up with new names to describe those styles. Name similarities will often imply closer ties in lineage. As a Brazilian Jiu Jitsu practitioner, I cringe when I see it spelled any other way, but also I have to recognize that I only feel that way because I have more exposure to that specific martial art/spelling.
  - toastal 3y ago
    The spelling ‘mistake’ makes it easier to web search.
- scq 3y ago
  There are multiple romanisation systems for Japanese, but the most common one is Hepburn. In Japan, Kunrei-shiki is sometimes used (especially by the government), which is designed with Japanese speakers in mind (vs Hepburn which was designed with English speakers in mind). It's jujutsu in both, but there are varying ways of representing the long vowel on the first "u" -- either omitting it (jujutsu), using a macron or circumflex (jūjutsu), or repeating the vowel (juujutsu). Ju-jitsu and jiu-jitsu are not correct in any romanisation system that I know of, I'm not really sure how they came about. Probably historical accident.
  - OJFord 3y ago
    So is it pronounced like it looks here? I've never seen this spelling before, and IME (and I assume GP's) everyone says 'jew-jit-sue'. But it's more like 'jew-jut-sue' (as in to jut out)?
stared 3y ago
As I see, it is both a DVCS and a meta-DVCS.
proto_lambda 3y ago
This looks really cool, I'll try it out on some of my repos to get a feel for it. Too bad support/discussion happens entirely on Discord.
- arxanas 3y ago
  Support/discussion happens a fair amount on GitHub Discussions and Issues as well.
- aseipp 3y ago
  Realistically, Jujutsu is a pretty new project and there are many features to add and lots and lots of code that needs to be written. There is a lot of talking that needs to happen, in other words. So, most of the developers and committers actively hang out and discuss things in Discord, yes, because it's convenient, and fast, and allows all the interested parties to be alerted. I say this as someone who started hacking/working on Jujutsu recently; having Discord has been nice for such a new project. The reality is that the project is in a part of its life where active discussion and feedback with the userbase is pretty valuable. So, you just go where the users are, and Discord is a big place for that. GitHub Issues and GitHub Discussions are also actively used by a lot of people, and you can just post things there. Every major committer watches those venues as well, AFAIK, I know my notifications are set up for it. Over time, assuming things are wildly successful, you'd probably have a lot of different venues to discuss things. I would view Discord mostly in the context of a new project that wants feedback, in that regard.
ephaeton 3y ago
my initial reaction, half OT: Ooof, random "ASCII" (actually: Unicode) art & dev-chosen colors, my bane of the "modern" CLI applications. That drawing you like? Doesn't work for me, give me the raw output please. Those colors you love? Aside of red-green weakness being the most dominant factor, what you're really doing is trying to set things apart, connotating color with semantics as well. It's nice this works fine on your white-on-black terminal. Have you tried this on a white-on-firebrick terminal? Yellow-on-green? Or anything else than _your_ "normative" setup? Man ... Also not sure the information presented is adequate. E.g. consider commit 76(2941318ee1) - jj makes it look like that was committed to that repository, while it was done to another. The git presentation looks more spot-on (for that particular commit, while the rest of the display is just a mess - ASCII art that does not add semantics, random colors); also where is 1e7d displayed in jj's output? Why is jj's order different? I remain unimpressed by both UIs. " Create a file at ~/.jjconfig.toml" ... $XDG_CONFIG_HOME ? When is that working copy committed? When I run jj? Why bother, when it's not working asynchronously and automatically? And if you commit working copies, do you sync under the hood with stuff the other folks you collaborate with? If not, why bother? Oh nice, a command to fix "stale" workspaces.. how about you don't let workspaces go stale? This may all seem to make sense to git-minded people, given the comments here. To me, neither jj nor git make sense (as fossil-minded person who has to work with git), so shrug enjoy.... ..but please fix that ASCII Art and Color Stuff, thank you very much.
- toastal 3y ago
  I don’t mind color, but pushing beyond the 16 colors is often a stretch without a very specific use case & bound to lead to a lack of legibility for some unless both foreground & background are defined—which has a tendency to look just as bad in a terminal. Similar issues happen with CSS when folks define color but not background color. But the one CLI trend that annoys me is using Emoji terminal. I often find their colors and shapes to be too distracting, commanding too much of the visual hierarchy of output. They also have a tendency to kind of fall apart when some characters or combinations of characters are missing or they no longer line up with the monospace output. A big part of CLI output is being able to scroll through the logged output, but the Emoji actually make visual scanning more difficult.
- 3y ago
forrestthewoods 3y ago
Fascinating. How does it handle very large repos and binary files? I want petabyte scale history and terabyte scale sparse clones. Alternatively, why use this over Git? I read the differences but feel like I’m missing a higher level difference. What problems does this solve that Git/Hg don’t solve already? What was the inspiration for starting the project?
josephg 3y ago
> If an operation results in conflicts, information about those conflicts will be recorded in the commit(s). The operation will succeed. You can then resolve the conflicts later. I’m really glad people are trying this out. I’ve spent the last decade or so playing with collaborative editing algorithms. Ideally I’d like tools like git to eventually be replaced by CRDT based approaches. CRDTs would let us use the same tools to do pair programming. CRDTs also handle complex merges better (no self-conflicts like you can get with git). And they’re generally a more powerful model. One problem with all modern text CRDTs (that I know of) is that they do automatic conflict-free resolution of concurrent edits. But when we collaborate offline on code, we usually want conflicts to show up and be resolved by hand. CRDTs should be able to handle that no problem - they have more information about the edit history than git, but doing this properly will (I think) require that we put the conflicts themselves into the data model for what a text file is. And I’m not sure how that should all work with modern text editors! Anyway, it sounds like jj has figured out the same trick. I’m excited to see how well it works in practice. With this we’re one step closer to my dream of having a crdt based code repository!
- ChadNauseam 3y ago
  You should check out Pijul, as it essentially implements everything you mentioned here. Pijul works on patches which are CRDTs, it makes conflicts a first-class concept, etc.
  - conaclos 3y ago
    I wonder: Is there a git backend for Pijul?
    - IlliOnato 3y ago
      I will be surprised if it's possible at all. And I think right now such a back-end would not be high on Pijul priority list. But if I am wrong, I would be very interested to learn about it!
      - 3y ago
OJFord 3y ago
I'm semi-sold on the idea of everything always being a commit, and lighter weight editing of those commits & structure, it sounds good. Except: 1. Not until I run some jj command? It's kind of begging for a 'jjd' isn't it? Or if you use an IDE you'd want/need it to be not just saving but doing some kind of 'jj nop'. 2. I haven't looked more into it than the readme, but that at least doesn't discuss (and I think it's important) withholding commits from the remote(s)? If everything's always(ish) committed, I've lost some control of untracked files or unstaged or locally stashed changes that I now need at the point of pushing; to mark those commits 'private' or something. I assume it does exist, and I'll look for it when I make time to play with it, but I find it slightly concerning (for how good it will be, or how important it's considered to be) that it's not more prominently discussed.
- arxanas 3y ago
  > Not until I run some jj command? It's kind of begging for a 'jjd' isn't it? Or if you use an IDE you'd want/need it to be not just saving but doing some kind of 'jj nop'. In practice, I find that it doesn't matter much. Some people do run `jj` in a loop incidentally (usually they have a live graph-log open on some screen). I suppose that you could get a "local history" feature like in some editors of more fine-grained changes to the codebase in this way. Folks have discussed adding a jj daemon, but so far it's not a priority. > I haven't looked more into it than the readme, but that at least doesn't discuss (and I think it's important) withholding commits from the remote(s)? If everything's always(ish) committed, I've lost some control of untracked files or unstaged or locally stashed changes that I now need at the point of pushing; to mark those commits 'private' or something. I assume it does exist, and I'll look for it when I make time to play with it, but I find it slightly concerning (for how good it will be, or how important it's considered to be) that it's not more prominently discussed. Usually it's pretty obvious to me which of my commits are public or private. When interfacing with GitHub, commits that are not reachable by a branch are definitely private . Additionally, commits without a description are private, and `jj git push` will warn you before allowing you to push them. There has been some discussion about adopting Mercurial-style "phases" (https://wiki.mercurial-scm.org/Phases https://wiki.mercurial-scm.org/Phases), which would explicitly accomplish the goal of marking commits public or private.
- 3y ago
ctafur 3y ago
I just find another alternative to Git called Grace. It's made by a Microsoft employee with F#.
- systems 3y ago
  I saw the presentation, its about having cloud ready or cloud native scm, i dont think this is a great idea git is about working locally github (or similar solutions) is the cloud part cloud native scm sound like a bad idea
malkosta 3y ago
Very impressive! Special congrats for not bloating the title with "in Rust"
derealized 3y ago
It's nice to have alternatives and maybe I have Stockholm Syndrome about this topic, but isn't git's complexity inherent to the area?
- yCombLinks 3y ago
  Git fails to make the common paths simple. There's no need for most of the complexity to be so prevalent in day to day use
Manjuuu 3y ago
I've just started looking into this, and since this seems to be doing a few automatic rebases under the hood, I wonder how this behave if commits get randomly pushed to origin. For git is always obvious when you are about to amend/overwrite a pushed HEAD and you can push forcefully only explicitly. Edit: anonymous branches are destined to be pushed remotely (to be reviewed and merged) and there is no local merge as far as I can tell, you can name these branches but no "merge back to development branch once done". Completely different workflow, having the ability to merge or "collapse" the anonymous branch to its parent would be nice, when you don't really need to push your feature branches anywhere.
- arxanas 3y ago
  > I wonder how this behave if commits get randomly pushed to origin You would expect the push to fail in the normal way, as if you had manually done the rebase, because your commit history may have diverged. That being said, I don't think this happens much in practice: the automatic rebases are typically for explicit history-rewriting operations that users tend to only do on their local work. If a user prefers to use a "no-rewriting" workflow, then they can certainly do so by simply not issuing the history-rewriting commands. > anonymous branches are destined to be pushed remotely (to be reviewed and merged) and there is no local merge as far as I can tell, you can name these branches but no "merge back to development branch once done". I'm not sure what you mean by this. You can do `jj merge` in a similar way to `git merge`, or you can do a rebase workflow.
  - Manjuuu 3y ago
    > You would expect the push to fail in the normal way, as if you had manually done the rebase, because your commit history may have diverged. That being said, I don't think this happens much in practice: the automatic rebases are typically for explicit history-rewriting operations that users tend to only do on their local work. If a user prefers to use a "no-rewriting" workflow, then they can certainly do so by simply not issuing the history-rewriting commands. Yeah, most of those rebases happen in the working copy or inside the anonymous branch. > I'm not sure what you mean by this. You can do `jj merge` in a similar way to `git merge`, or you can do a rebase workflow. I just meant merging a feature branch back to its parent, jj merge exists but it's not obvious which revisions you are supposed to pass to it and jj log doesn't even seem to be able to update the HEAD for the parent branch. It should be an easy operation but it's not, clearly not the suggested workflow (or at least, not documented from what I've read).
miah_ 3y ago
Oh its from Google? Eh. Pass. It will either be killed in 5 years, or be pitted against Git in an attempt to take over the community.
- mrd3v0 3y ago
  The "disclaimer" is quite interesting. Starts off with "this is not a Google product" and ends it with the fact that it is indeed their full-time project at Google. I wish these well-intentioned Googlers realise what they are doing.
- mrd3v0 3y ago
  Oh, and you might be interested in https://radicle.xyz/ https://radicle.xyz/. I tried it a while ago, was stable and has nice aesthetics to it as a bonus.
Groxx 3y ago
>safe replication via rsync, Dropbox, or distributed file system Neat. I've been leaning more and more towards systems that are dumb-sync-friendly because I can throw them anywhere with anything and they just work. Always glad to see new things doing this!
- snthpy 3y ago
  Can someone say more about this? I've heard of this issue before but haven't experienced it myself. How does it arise, I.e. what's the race condition between git and rsync/Dropbox/... that causes problems?
  - Groxx 3y ago
    Git mutates files to do many of its normal operations. Dumb-syncing without being perfectly up to date before you disconnect and switch to another machine and start making more changes means you risk conflicts (new conflict-named files in Dropbox, silently clobbered changes in many, etc), and git has essentially no way to notice this and warn you about what happened or recover what you lost. So you do your stuff, later discover the sync error when you reconnect, and now you have to choose losing data or understanding git's plumbing and raw data well enough to save both by hand. --- For example, branches. From what I can tell (I'm moderately confident here, but definitely not 100%): Git stores branches as a file at .git/refs/heads/branch-name which contains the current commit SHA. When you make a new commit in that branch, it modifies the file's contents to contain the new SHA. Syncing a conflicting change here means... well lots of possibilities. Maybe one write silently wins and the other SHA gets silently garbage collected eventually, maybe there's now a new branch with a conflicty name, maybe you have a broken file because it contains a `diff` conflict and it has <<<===>>> markers, maybe demons erupt from your nostrils. Jujutsu stores branches as a folder at some/path/branch-name/. The current head of the branch is a file in that folder with the SHA as its filename (the file is empty), giving you some/path/branch/c0ffee . If you sync changes from somewhere else due to concurrent changes to your clone, it either agrees and there's no harm, or it becomes a new file in that folder, some/path/branch/00f . Your local tool doesn't know which is correct, but it can tell that a conflict occurred, and both actions' results are still available. --- That's a thing you have to design carefully around, so it's completely understandable that it's not the default. But one of the benefits is that it means you don't need special protocols to exchange data, so tons of things simply work correctly without further effort. Git has to use lock files to protect its internals, and they have numerous issues and are completely useless in some situations (e.g. NFS, Dropbox). Jujutsu simply doesn't need them, and works safely regardless of your system or usage patterns (for this at least, dunno about everything). All this^ is why I pay to store my git repos in a git host rather than simply using my own backup systems (and why I don't have two remote backups). And it's why I avoid SQLite for much of my heavy-use personal backed-up stuff - it makes one large file that mutates, so fully syncing is a MUST before making any changes. Same with keepass - one large mutating database (but it has pretty good database merging built in, so the dozen or so conflict files I've gained are easy to resolve). There are pros and cons to splitting things up into a million files of course, but I run into sync issues pretty regularly so that's the pain I feel most keenly.
9dev 3y ago
I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit tags - everything at once, with keyboard shortcuts. Apparently, I'm in the minority here (also considering all the talk about git being such an essential skill that real programmers can issue commands blindfold). Why is that?
- calvinmorrison 3y ago
  Because I have two types of people who understand git on my team. People who use the CLI and people who don't understand git and just start clicking buttons
  - Double_a_92 3y ago
    You forgot the people that only know: git commit -a -m "foobar" and think that's better than using a GUI to easily make clean commits.
    - calvinmorrison 3y ago
      If I could enforce one thing, it would be to REQUIRE partial commits for everything from an UI. I can't tell you the amount of commits I have seen that need to be cleaned up from spare debugging statements to vendor files to things that need to be added into the git ignore. The other thing would be to make sure people understand what things like 'squash' and 'rebase' to and how they effect the tree. Also to explain if you have multiple features, please don't work on it all on the same branch unless you have too. (This is a internal workflow, not really related to git but how we handle merges)... Yeah, a UI could be just fine for an experienced git user. In my experience though, experienced git users don't use it though, so it's a moot point.
      - 3y ago
dilap 3y ago
Extremely cool looking project which I would love to try, alas I am blocked by the lack of git-lfs support, for now https://github.com/martinvonz/jj/issues/80 https://github.com/martinvonz/jj/issues/80
Double_a_92 3y ago
I never understand such projects... How is git hard, especially compared to the complexity of most things that you would even commit to your git repository?
- kuchenbecker 3y ago
  Working on large complex projects the main branch will have dozens or hundreds of commits per day pushed continuously. The value is a consistent and linear commit history moving from known-state to known state. Facebook version control system built on mercurial is the best I've used. One of the huge benefits of the rebase based workflow is commits can be reordered and land as they pass tests rather than a single linear commit history.
  - Double_a_92 3y ago
    You all work on one shared main branch, without any feature branches? Isn't it horrible to have other people half-finished code in the code that you are trying to work with?
    - kuchenbecker 3y ago
      Work in whatever branch you want, but if you want to merge to main and deploy it better be a stack of PRs that merge cleanly and don't expect others to wait or serialize on your change.
ChrisArchitect 3y ago
Some more discussion a year ago: https://news.ycombinator.com/item?id=30398662 https://news.ycombinator.com/item?id=30398662 Anything new in the project?
glencbz 3y ago
I've been using jj daily for close to a year and without a doubt, it blows the Git UX out of the water. I'm very particular about breaking up my changes into atomic commits, so a killer feature for me is automatic rebasing. Since conflicts can be recorded in commits, you never have to stop a rebase to fix conflicts like you do in Git and Mercurial - history operations work exactly the way a human would expect. Modify a commit? Delete it altogether? jj just automatically rebases all of the descendants for you (and yes, it handles multiple children like Mercurial evolve and unlike Git rebase). On top of this is a great set of primitives for manipulating commit history - `jj move|restore` to move|copy changes from one commit to another, `jj split` to break up commits, `jj rebase` to move commits around. _Everything_ is inside commit history (no "worktree", no "index"), so one set of commands and flags will do everything you want. The operation log is also incredible. Most operations can be undone with zero problems. Compare that to Git, where your best hope to fix a bad rebase/commit --amend is to scrounge around the reflog for the right commits and manually fixing up your refs. The biggest pain points for me are: - Automatic working copy commit sometimes tries to commit things I don't want. Usually .gitignore has things covered, but sometimes moving files around and rebasing commits breaks things. Fixing up broken commits with `jj split|restore` is pretty easy though. - No rename detection. jj doesn't handle merges as elegantly as Git. jj devs are thinking about this, but haven't quite cracked it. I'm not sure how long that will take.
predictabl3 3y ago
I'm thrilled to see the comments here. Jujube is a gem, an absolute gem. Ive never felt so empowered or fearless to make changes in a git repo, and never more confident that it would be really hard to lose work, unlike with git.
kccqzy 3y ago
Has anyone tried both this and Sapling? https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ https://engineering.fb.com/2022/11/15/open-source/sapling-so... Both of these are on my TODO lists but haven't had time to try them yet.
- arxanas 3y ago
  Check out https://github.com/martinvonz/jj/blob/main/docs/sapling-comparison.md https://github.com/martinvonz/jj/blob/main/docs/sapling-comp... In my opinion: - Sapling is much more mature/full-featured at this point. - Jujutsu improves source control workflows in a more principled way. - Jujutsu currently supports colocation with a Git repo, while Sapling requires that the Git repo be kept separately.
bedros 3y ago
what's the advantage of native backend compared to git repo backend?
- arxanas 3y ago
  > At this time, there's practically no reason to use the native backend. The backend exists mainly to make sure that it's possible to eventually add functionality that cannot easily be added to the Git backend. From the README, no advantage for now.
pyrelight 3y ago
Why/how did Git's UX become so bad?
- KingMob 3y ago
  Torvalds is not a UX person. If the creator is indifferent, you get a slew of commands and flags that map to the data structures and idiosyncrasies of the creator, rather than anything presenting a cohesive API to the outside world.
eviks 3y ago
Is there any good GUI client supporting this?
- arxanas 3y ago
  One of our Discord members had a prototype implementing support in IntelliJ if you want to try that. Other than that, I'm not aware of any jj GUI clients. However, you can use jj directly in Git repositories with the colocated mode and then continue using your preferred Git GUI client. (Obviously, you miss out on the jj-only features.)
  - eviks 3y ago
    Thanks, maybe will try the co-located mode since I only use cli git for some operations not covered by GUI, and git cli UI is atrocious
rcme 3y ago
This seems like a really unnecessary amount of overhead. With build times often taking multiple minutes, being able to multi-task is essential. I often work on two things at once. That seems difficult / impossible with this.
- arxanas 3y ago
  What does the version control system have to do with build times and multi-tasking? I use jj in repositories with long builds, but I don't see what it has to do with that.
  - rcme 3y ago
    Every jj command creates a commit. So if you have two unrelated pieces of work you need to split all the commits created.
    - arxanas 3y ago
      I see that the README is unclear or even misleading on this point. How it works is that, upon each command, the commit corresponding to the working copy is updated in a similar way as `git commit --amend`. You will typically only have one "working copy commit", which corresponds to "unstaged changes" in Git. The difference is that instead of using special-purpose commands like `git add` to interact with the staging area, you instead use the same set of commands that you would use to manipulate other commits. (There is a `jj commit` convenience command to model the common case of adding a commit message to the working copy commit and then creating a new working copy commit on top of it.)
trowaway344988 3y ago
What sourcery is that? It highlights the first character(s) of the hash! Does [git log] have that? I think too much hash looks noisy. All I could find was: $ git rev-parse --short=4 HEAD 8f60
frizlab 3y ago
> I (Martin von Zweigbergk) have almost exclusively used `jj` to develop the project itself since early January 2021. I haven't had to re-clone from source (I don't think I've even had to restore from backup). WTF?? Me neither on none of my git project. Ever. So what? I’m a git genius?? The truth is I don’t even understand how one can reach a point where re-cloning a (git) repo is needed: git can always reset --hard and it has never ever failed for me, even during complicated interactive rebase and co.

673 points by lemper 3y ago

Does anyone have experience with large repo's of say, 100 GB? Does jj incur performance penalty's compared to native git?

arxanas 3y ago
It depends on whether you're talking about 100 GB repository size or working copy size. - Currently no partial/shallow clones, so you need to materialize the entire repo on disk. - Working copy status can take a while (see https://github.com/martinvonz/jj/issues/1841 https://github.com/martinvonz/jj/issues/1841 for tracking issue). This can be ameliorated at present by configuring Watchman as a filesystem monitor, and work is underway to improve status further. - No support for Git LFS at present (even in colocated repos). When using the Git backend with jj, you would expect the same problems with regards to large file management. - I haven't noticed any particular performance issues when interacting with the object store a large repository. It should be approximately the same as for Git since it uses libgit2 for the Git backend. - Faster for operations that can be done in-memory in jj but only on-disk with Git, such as various rebase operations.

mcqueenjordan 3y ago

Oh wow, this looks really promising. I've been playing with a homegrown centralized VCS client and server project, aimed at basically being the VCS host for monorepos, and this looks like a much better foundation for the VCS layer.

teleforce 3y ago

Jujutsu started as author's personal project and now author's full-time project at Google. It's presented at Git Merge 2022: Jujutsu: A Git-Compatible VCS - Git Merge 2022: Video: https://youtu.be/bx_LGilOuE4 https://youtu.be/bx_LGilOuE4 Slides: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX_L4bQ9NMcYOp1isn17kTC_M/view https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX...

robertlagrant 3y ago
> started as author's personal project and now author's full-time project at Google That's got to feel good!
- jrpelkonen 3y ago
  Absolutely, good for the author. However, given the numerous examples of Google pulling the plug on nonessential projects, I don’t see this as strictly positive development.
  - scq 3y ago
    Well, it is open source, so the author or someone else could always pick it up again as a personal project if that happened.
    - sdesol 3y ago
      Based on this https://devboard.gitsense.com/martinvonz/jj https://devboard.gitsense.com/martinvonz/jj it looks like there are two people working on it full-time, with 7 people contributing at least 500+ lines of code churn and 14 contributing code changes. Overall the project is fairly healthy and there does appear to be enough people engaged with the project that it should continue, should Google pull the plug. Full disclosure: This is my tool
  - collinmanderson 3y ago
    Google should go back to slapping a huge "Beta" label on every single product.

gyulai 3y ago

I had to choose a VCS for a project a year ago. At that point jujutsu looked extremely promising but immature. It's great to see that so much progress has been made. I can't wait to give it another go, the next time I get to choose a VCS for something. Innovation in this space is desperately needed.

zelphirkalt 3y ago

I would say "What a weird name for a VCS. Whether that will work ...", but then I have to remind myself of the dictionary meaning of "git". So who knows. Maybe we will be adopting all kinds of martial arts terminology. For example: "I use Karate to manage my code. I divide everything using chops. When a kata is done, ..."

dagurp 3y ago
It's a horrible name to pronounce for many non-English speakers.
- hosh 3y ago
  Ironic because it’s a Japanese name, not English. According to the readme, “jj” was chosen because it was easy to type, and a name was found to fit that.
  - avgcorrection 3y ago
    [flagged]
- apeescape 3y ago
  Did you know that the English way to pronounce "jujutsu" isn't how the Japanese pronounce it? The Japanese way to pronounce it could actually be a lot easier for many non-English speakers (I'd anyway argue it's a common enough word that people are familiar enough with it to pronounce it in a way that's comfortable to them).
  - nordsieck 3y ago
    > Did you know that the English way to pronounce "jujutsu" isn't how the Japanese pronounce it? Really? The wiki audio sample[1] seems fairly close to how people in the US pronounce the word, just with a more emphasized first syllable. --- 1. https://upload.wikimedia.org/wikipedia/commons/f/f1/Ja-Jujutsu.oga https://upload.wikimedia.org/wikipedia/commons/f/f1/Ja-Jujut...

seertaak 3y ago

I'm definitely going to try this, looks really sweet.

shandor 3y ago

The automatic rebase and jj diffedit sound very nice addition to some of my most-used git workflows. Looks very interesting, will definitely have to give this a deeper try.

mcluck 3y ago

Looks really cool! One thing I'm not clear on from the docs: does it support ignoring changes to some files for "real" commits? For example, a repo at work has a file used for mocking up feature flags. The file is tracked but it's encouraged to edit it when testing things, just don't commit your changes. If I'm not mistaken, I'd have to remember to undo changes to that file before "describing" the commit. Is that right?

ilyagr 3y ago
The commit will indeed be created immediately, there's no way to prevent that except for .gitignore I'm aware of. Until you run `jj describe`, it won't have a description. However, if you don't manually put a branch on it, it'll never get pushed and will stay on your machine only. You can sit on this personal commit and rebase it on top of any other commit to move around the repo, again and again if you like.
psd1 3y ago
I know the nuisance of having to tiptoe around files you don't want to add to history. In case it helps your use case: git update-index --assume-unchanged <file> git update-index --no-assume-unchanged <file> This would ignore changes while you're testing - but you have to remember to turn it off or, iiuc, you won't pull intentional changes either. You might find hooks useful too. Not to assume your knowledge, these are shell scripts placed in .git/hooks that are invoked, e.g., before commit or before push. You could have it parse git status, detect changes to <file>, prompt for confirmation if changed and remove from working set if the change is unintentional.
- mcluck 3y ago
  I never knew about the `update-index` command. That's going to save me a lot of time. Thanks!

geenat 3y ago

Explain how does it handle large binary files? (the UX around this is the shortcoming of all current DVCS..)

ozkatz 3y ago
Might want to look at purpose built tools for that such as lakeFS (https://github.com/treeverse/lakeFS/ https://github.com/treeverse/lakeFS/) * Disclaimer: I'm one of the creators/maintainers of the project.
dahhowl 3y ago
README says that the git backend is the recommended backend, as the "native" one has no additional features, so I imagine: it handles them the same as git (ie. they are just objects in the .git repo data, and each time you change them you add a new one, and they are poorly compressible and optimizable) -- which is, I imagine, the problem you're referring to.
- rkangel 3y ago
  It won't be completely the same as git, because the client fetches stuff more lazily (according to the linked presentation). So the backend will still fill up with stuff and need lots of storage, but the clients then won't necessarily slow down in the same way. That said, any git users will still get slowed down - only jj users would see the benefit. Git does have better features these days for shallow clones though and even git is on the way to killing off the need for LFS.
Beldin 3y ago
Now I'm curious: how would you want a DVCS to handle large binaries?
- Ygg2 3y ago
  Partial checkout/Shallow first checkout. JJ doesn't seem to do that though, right?
- chaxor 3y ago

gautamcgoel 3y ago

I am certainly no expert in version control systems, but I've gotta say that it's really wonderful to see a project that builds on the algorithmic and cultural successes of Git but with a simplified and modernized approach. The reason that Git took over the open-source world is two-fold: first, it was adopted by Linux, which ended up being the most influential OSS project of all time. Second, the Git model, which is distributed and egalitarian at its core, is a natural model for a fast-paced, globally distributed community of developers. These are both reasons to appreciate Git, but they do not imply that Git is the final word in version control. I'm excited to see innovation in this space!

robertlagrant 3y ago
> which is distributed and egalitarian at its core, is a better model for a fast-paced, globally distributed community of developers than previous monorepo systems like Mercurial I'm a bit confused by this. I don't think that's what monorepo means, is it? Monorepo is what you choose to put in a repo? And I thought Mercurial was extremely similar to Git as it's also a DVCS?
- pmezard 3y ago
  Git and Mercurial are fairly similar, at least compared to what OP is apparently hinting at. Different tech and different internal architectures, but both of them are DVCS offering roughly equivalent workflows.
- brmgb 3y ago
  It is. The OP is wrong, probably because he has never used Mercurial, which wouldn’t be that surprising given it doesn’t have a lot of users outside of the few remaining companies still using it.
  - robertlagrant 3y ago
    I've never used it, but I have read hg.init[0]! [0] https://hginit.com https://hginit.com
- 3y ago

pxc 3y ago

This Git-compatibility-first approach makes Jujutsu seem like a stronger contender to replace Git than I've seen so far. I'm curious about its management of conflicts. I know that pmeunier has taken a lot of care to formally work out a theory of patches to drive Pijul, and that unsound or problematic notions of patches/conflicts can lead to serious problems— they say that's what led to all the performance problems with Darcs, right? I'd love if the comparison page on the repo wiki gave a little more detail than that Pijul's handling of conflicts seems 'similar'.

arxanas 3y ago
There is a little more detail here: https://github.com/martinvonz/jj/blob/main/docs/technical/conflicts.md https://github.com/martinvonz/jj/blob/main/docs/technical/co... Storing the conflicts symbolically in this way lets you reproduce the conflicts later and even auto-resolve certain conflicts, but it doesn't address resolving the actual contents of conflicts. You could probably use Pijul as a jj backend and get the best of both worlds (if someone were to implement it).

vesinisa 3y ago

This looks promising. One question I had after reading about its git compatibility is that they seem mostly focused on the use case where a Jujutsu user accesses a git repository (hosted by e.g. GitHub) with jj. But does it support the converse way of working, i.e. accessing a native Jujutsu repository with git? I ask this because most developers are already quite familiar with the git CLI so in production use one would probably see developers co-working with jj and git in the same codebase. Or would the realistic production scenario be always using git (as opposed to native Jujutsu database) as the backing storage to allow accessing both with git and jj CLIs?

UzEE 3y ago
I would assume there would always be the expectation that you either use Jujitsu as a frontend to a git repo, or have a complete Jujitsu based remotes. If you're going to work on and contribute to a project that is already using Jujitsu, it is reasonable to expect that you'd adapt your workflow to the project itself and not the other way around.
- vesinisa 3y ago
  Thanks, it makes sense. I don't understand why this was downvoted.
me-vs-cat 3y ago
The README's footnote: At this time, there's practically no reason to use the native backend. The backend exists mainly to make sure that it's possible to eventually add functionality that cannot easily be added to the Git backend.
- sedatk 3y ago
  That footnote has a “won’t be big and professional like GNU” feeling to it.

toomim 3y ago

> The working copy is automatically committed. Thank goodness. This has been needed for a long time. Props to the author Martin for investing himself in creating elegance!

ocharles 3y ago

Nice to see this posted here. I switched over to it about 2-3 weeks ago, and I haven't looked back. It took a lot of mental rewiring, but I really enjoy the workflow `jj` provides. There's no longer a time to think about what's being committed, because all file changes automatically amend the working copy commit. Of course, sometimes you don't want this, so you have things like the ability to split a commit into two, moving commits, etc. But having _everything_ operate on commits is really nice! Other niceities that I like: - `jj log` is awesome for getting an overview of all your branches. If, like me, you have a lot of work in progress at once, this provides a great map - Conflict resolution is really cool, as you can partially resolve conflicts, and then switch branches. Conflicts are also tracked specially, but I haven't done too much with this yet. - The abbreviated changeset ids are really handy. I often will just `jj log` (or in my case just `jj` as that's the default), notice a changeset I want to rebase, then run `jj rebase -s qr -d master`. `qr` here is an abbreviated changeset id for a branch/commit, and usually much quicker than typing the branch name out! This will probably change when clap gets updated to support dynamic tab-completion though.

TylerE 3y ago
What happens if you accidentally save a file with some sort of secret that gets sucked in?
- Certhas 3y ago
  Isn't the idea that you continue editing the working copy commit until you actually commit it? Also from the documentation: https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md https://github.com/martinvonz/jj/blob/main/docs/git-comparis... "As a Git power-user, you may think that you need the power of the index to commit only part of the working copy. However, Jujutsu provides commands for more directly achieving most use cases you're used to using Git's index for. For example, to create a commit from part of the changes in the working copy, you might be used to using git add -p; git commit. With Jujutsu, you'd instead use jj split to split the working-copy commit into two commits. To add more changes into the parent commit, which you might normally use git add -p; git commit --amend for, you can instead use jj squash -i to choose which changes to move into the parent commit."

roytam87 3y ago

... so a Jujutsu Kaisen begins if getting a commit conflict?

KingMob 3y ago
Really sad jj wasn't short for "JoJo's Bazaar Gitventure".

baq 3y ago

Related DVCS: https://pijul.org/ https://pijul.org/ I need to try it out at $WORK since constant rebasing on a busy repo with a hundred or so committers is not fun.

goku12 3y ago
Pijul needs a 1.0 release if it wants wide adoption. I don't understand why they wait. Meanwhile, if rebasing on git is an issue, you should probably try stacked-git (https://stacked-git.github.io/ https://stacked-git.github.io/). It manages commits as a stack of patches - like quilt, but on top of git.
- toastal 3y ago
  git-branchless also fits in the same vein as stacked-git with everyone’s favorite commands like `record`, `unrecord`, & `smartlog`. That said, I’ve been using darcs this past month & the performance issue seem overblown (/ largely fixed, tho not fully addressed) while the stability & usability are there. Email support is a bonus.

awestroke 3y ago

"working copy is automatically committed" seems like a good idea at first glance, but there are many situations where this is not a good idea: - when new artefact files are added and you have not yet added them to .gitignore, they'll be automatically committed - when you have added ignored files in one branch and switch to another branch, the files will still be in your working copy but not listed in your .gitignore file, and would then be automatically committed - staging only some files and comitting is much easier than splitting a commit after the fact

Certhas 3y ago
I don't see how these things are an issue in jjs design, nor do I see how staging some files is easier than splitting a commit after the fact... Check out the documentation, many of the cases you are concerned about are explicitly mentioned: https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md https://github.com/martinvonz/jj/blob/main/docs/git-comparis...
- tom-dixon 3y ago
  Constantly having to split after the auto-commits feels like I have to keep fighting this automated commit system. It's a bit like the autosave feature of text editors, which some people find useful, but I never felt like it's needed. A big downside I can see is that sensitive information might end up in the repo forever because I forgot to revert the auto commit.
  - sanderjd 3y ago
    I always end up reading through my commit diffs while committing and then maybe like a third of the time I edit something about them. So for me this seems like it could be a natural acknowledgement of that; just make that editing after the fact be the primary / only workflow. Haven't used this yet so no idea if it's actually great or terrible, but I like to see ingrained conventional wisdom challenged like this. We're always in some local maximum, so I think it's often interesting to be pushed in some new direction on the gradient.
  - 3y ago

Certhas 3y ago

This looks incredibly good to me. The working copy as "commit being worked on right now" is a much simpler data structure than the "working copy + stash + staging area" of git. I really hope this succeeds... VSC support would be a great start...

jimsimmons 3y ago

This project is a great example of subliminal marketing. It is less apparent now but still, the repeated flex of “Google”, 20% project etc when no typical reader would assume them is classic corporate charlatanry. Shame because I like the project otherwise

psd1 3y ago
It may be a calculated move. But, more charitably, perhaps it is simply unpolished communication.

contctlink 3y ago

I thought it was about UFC for a sec :)

anentropic 3y ago

I was expecting to be meh, but by halfway through the readme I was thinking "this actually sounds great!"

frizlab 3y ago
I was (and still am) meh. YMMV I guess.

e12e 3y ago

Looks interesting. Unfortunately doesn't support signing commits - apparently it's possible via "jj export" and using classical git: https://github.com/martinvonz/jj/issues/58#issuecomment-1247940400 https://github.com/martinvonz/jj/issues/58#issuecomment-1247...

rslabbert 3y ago
The plan for how the add signed commits is there, and the work isn't that hard (especially as gitoxide continues to add functionality), it just has to be pushed over the line and I've been a bit slack on getting that going. There's definitely nothing foundational blocking it though and it will happen one day if you'd like to give it a go in the meantime.

k__ 3y ago

Do I understand this correctly? This is some kind of background process that automatically commits any changes you make. You can use the CLI to check what it did and if you want to modify the auto commits.

OJFord 3y ago
No daemon, it happens 'whenever you run a command'. > Commands snapshot the working copy before they start, then the update the repo, and then the working copy is updated (if the working-copy commit was modified). Almost all commands (even checkout!) operate on the commits in the repo, leaving the common functionality of snapshotting and updating of the working copy to centralized code.
- systems 3y ago
  so commit is a side effect, not an explicit action weird choice, isnt explicit always better than implicit

psd1 3y ago

The tool looks great; I have a hurdle to overcome with the name. I'm long accustomed to spelling it, in English, as Jujitsu. I've also seen Jiu-jitsu. "jutsu" is much less common, IME. Is there such thing as canonical Romanisation of Nipponese? I can deal with a project being "wrong" better than not knowing which of us is wrong.

brendev 3y ago
I think your question is getting into the field of martial arts lineage. People might have their own narratives/ mythologies around this, but here's the most neutral way I can explain it: As techniques and styles evolve over the years, people come up with new names to describe those styles. Name similarities will often imply closer ties in lineage. As a Brazilian Jiu Jitsu practitioner, I cringe when I see it spelled any other way, but also I have to recognize that I only feel that way because I have more exposure to that specific martial art/spelling.
- toastal 3y ago
  The spelling ‘mistake’ makes it easier to web search.
scq 3y ago
There are multiple romanisation systems for Japanese, but the most common one is Hepburn. In Japan, Kunrei-shiki is sometimes used (especially by the government), which is designed with Japanese speakers in mind (vs Hepburn which was designed with English speakers in mind). It's jujutsu in both, but there are varying ways of representing the long vowel on the first "u" -- either omitting it (jujutsu), using a macron or circumflex (jūjutsu), or repeating the vowel (juujutsu). Ju-jitsu and jiu-jitsu are not correct in any romanisation system that I know of, I'm not really sure how they came about. Probably historical accident.
- OJFord 3y ago
  So is it pronounced like it looks here? I've never seen this spelling before, and IME (and I assume GP's) everyone says 'jew-jit-sue'. But it's more like 'jew-jut-sue' (as in to jut out)?

stared 3y ago

As I see, it is both a DVCS and a meta-DVCS.

proto_lambda 3y ago

This looks really cool, I'll try it out on some of my repos to get a feel for it. Too bad support/discussion happens entirely on Discord.

arxanas 3y ago
Support/discussion happens a fair amount on GitHub Discussions and Issues as well.
aseipp 3y ago
Realistically, Jujutsu is a pretty new project and there are many features to add and lots and lots of code that needs to be written. There is a lot of talking that needs to happen, in other words. So, most of the developers and committers actively hang out and discuss things in Discord, yes, because it's convenient, and fast, and allows all the interested parties to be alerted. I say this as someone who started hacking/working on Jujutsu recently; having Discord has been nice for such a new project. The reality is that the project is in a part of its life where active discussion and feedback with the userbase is pretty valuable. So, you just go where the users are, and Discord is a big place for that. GitHub Issues and GitHub Discussions are also actively used by a lot of people, and you can just post things there. Every major committer watches those venues as well, AFAIK, I know my notifications are set up for it. Over time, assuming things are wildly successful, you'd probably have a lot of different venues to discuss things. I would view Discord mostly in the context of a new project that wants feedback, in that regard.

ephaeton 3y ago

my initial reaction, half OT: Ooof, random "ASCII" (actually: Unicode) art & dev-chosen colors, my bane of the "modern" CLI applications. That drawing you like? Doesn't work for me, give me the raw output please. Those colors you love? Aside of red-green weakness being the most dominant factor, what you're really doing is trying to set things apart, connotating color with semantics as well. It's nice this works fine on your white-on-black terminal. Have you tried this on a white-on-firebrick terminal? Yellow-on-green? Or anything else than _your_ "normative" setup? Man ... Also not sure the information presented is adequate. E.g. consider commit 76(2941318ee1) - jj makes it look like that was committed to that repository, while it was done to another. The git presentation looks more spot-on (for that particular commit, while the rest of the display is just a mess - ASCII art that does not add semantics, random colors); also where is 1e7d displayed in jj's output? Why is jj's order different? I remain unimpressed by both UIs. " Create a file at ~/.jjconfig.toml" ... $XDG_CONFIG_HOME ? When is that working copy committed? When I run jj? Why bother, when it's not working asynchronously and automatically? And if you commit working copies, do you sync under the hood with stuff the other folks you collaborate with? If not, why bother? Oh nice, a command to fix "stale" workspaces.. how about you don't let workspaces go stale? This may all seem to make sense to git-minded people, given the comments here. To me, neither jj nor git make sense (as fossil-minded person who has to work with git), so shrug enjoy.... ..but please fix that ASCII Art and Color Stuff, thank you very much.

toastal 3y ago
I don’t mind color, but pushing beyond the 16 colors is often a stretch without a very specific use case & bound to lead to a lack of legibility for some unless both foreground & background are defined—which has a tendency to look just as bad in a terminal. Similar issues happen with CSS when folks define color but not background color. But the one CLI trend that annoys me is using Emoji terminal. I often find their colors and shapes to be too distracting, commanding too much of the visual hierarchy of output. They also have a tendency to kind of fall apart when some characters or combinations of characters are missing or they no longer line up with the monospace output. A big part of CLI output is being able to scroll through the logged output, but the Emoji actually make visual scanning more difficult.
3y ago

forrestthewoods 3y ago

Fascinating. How does it handle very large repos and binary files? I want petabyte scale history and terabyte scale sparse clones. Alternatively, why use this over Git? I read the differences but feel like I’m missing a higher level difference. What problems does this solve that Git/Hg don’t solve already? What was the inspiration for starting the project?

josephg 3y ago

> If an operation results in conflicts, information about those conflicts will be recorded in the commit(s). The operation will succeed. You can then resolve the conflicts later. I’m really glad people are trying this out. I’ve spent the last decade or so playing with collaborative editing algorithms. Ideally I’d like tools like git to eventually be replaced by CRDT based approaches. CRDTs would let us use the same tools to do pair programming. CRDTs also handle complex merges better (no self-conflicts like you can get with git). And they’re generally a more powerful model. One problem with all modern text CRDTs (that I know of) is that they do automatic conflict-free resolution of concurrent edits. But when we collaborate offline on code, we usually want conflicts to show up and be resolved by hand. CRDTs should be able to handle that no problem - they have more information about the edit history than git, but doing this properly will (I think) require that we put the conflicts themselves into the data model for what a text file is. And I’m not sure how that should all work with modern text editors! Anyway, it sounds like jj has figured out the same trick. I’m excited to see how well it works in practice. With this we’re one step closer to my dream of having a crdt based code repository!

ChadNauseam 3y ago
You should check out Pijul, as it essentially implements everything you mentioned here. Pijul works on patches which are CRDTs, it makes conflicts a first-class concept, etc.
- conaclos 3y ago
  I wonder: Is there a git backend for Pijul?
  - IlliOnato 3y ago
    I will be surprised if it's possible at all. And I think right now such a back-end would not be high on Pijul priority list. But if I am wrong, I would be very interested to learn about it!
    - 3y ago

OJFord 3y ago

I'm semi-sold on the idea of everything always being a commit, and lighter weight editing of those commits & structure, it sounds good. Except: 1. Not until I run some jj command? It's kind of begging for a 'jjd' isn't it? Or if you use an IDE you'd want/need it to be not just saving but doing some kind of 'jj nop'. 2. I haven't looked more into it than the readme, but that at least doesn't discuss (and I think it's important) withholding commits from the remote(s)? If everything's always(ish) committed, I've lost some control of untracked files or unstaged or locally stashed changes that I now need at the point of pushing; to mark those commits 'private' or something. I assume it does exist, and I'll look for it when I make time to play with it, but I find it slightly concerning (for how good it will be, or how important it's considered to be) that it's not more prominently discussed.

arxanas 3y ago
> Not until I run some jj command? It's kind of begging for a 'jjd' isn't it? Or if you use an IDE you'd want/need it to be not just saving but doing some kind of 'jj nop'. In practice, I find that it doesn't matter much. Some people do run `jj` in a loop incidentally (usually they have a live graph-log open on some screen). I suppose that you could get a "local history" feature like in some editors of more fine-grained changes to the codebase in this way. Folks have discussed adding a jj daemon, but so far it's not a priority. > I haven't looked more into it than the readme, but that at least doesn't discuss (and I think it's important) withholding commits from the remote(s)? If everything's always(ish) committed, I've lost some control of untracked files or unstaged or locally stashed changes that I now need at the point of pushing; to mark those commits 'private' or something. I assume it does exist, and I'll look for it when I make time to play with it, but I find it slightly concerning (for how good it will be, or how important it's considered to be) that it's not more prominently discussed. Usually it's pretty obvious to me which of my commits are public or private. When interfacing with GitHub, commits that are not reachable by a branch are definitely private . Additionally, commits without a description are private, and `jj git push` will warn you before allowing you to push them. There has been some discussion about adopting Mercurial-style "phases" (https://wiki.mercurial-scm.org/Phases https://wiki.mercurial-scm.org/Phases), which would explicitly accomplish the goal of marking commits public or private.
3y ago

ctafur 3y ago

I just find another alternative to Git called Grace. It's made by a Microsoft employee with F#.

systems 3y ago
I saw the presentation, its about having cloud ready or cloud native scm, i dont think this is a great idea git is about working locally github (or similar solutions) is the cloud part cloud native scm sound like a bad idea

malkosta 3y ago

Very impressive! Special congrats for not bloating the title with "in Rust"

derealized 3y ago

It's nice to have alternatives and maybe I have Stockholm Syndrome about this topic, but isn't git's complexity inherent to the area?

yCombLinks 3y ago
Git fails to make the common paths simple. There's no need for most of the complexity to be so prevalent in day to day use

Manjuuu 3y ago

I've just started looking into this, and since this seems to be doing a few automatic rebases under the hood, I wonder how this behave if commits get randomly pushed to origin. For git is always obvious when you are about to amend/overwrite a pushed HEAD and you can push forcefully only explicitly. Edit: anonymous branches are destined to be pushed remotely (to be reviewed and merged) and there is no local merge as far as I can tell, you can name these branches but no "merge back to development branch once done". Completely different workflow, having the ability to merge or "collapse" the anonymous branch to its parent would be nice, when you don't really need to push your feature branches anywhere.

arxanas 3y ago
> I wonder how this behave if commits get randomly pushed to origin You would expect the push to fail in the normal way, as if you had manually done the rebase, because your commit history may have diverged. That being said, I don't think this happens much in practice: the automatic rebases are typically for explicit history-rewriting operations that users tend to only do on their local work. If a user prefers to use a "no-rewriting" workflow, then they can certainly do so by simply not issuing the history-rewriting commands. > anonymous branches are destined to be pushed remotely (to be reviewed and merged) and there is no local merge as far as I can tell, you can name these branches but no "merge back to development branch once done". I'm not sure what you mean by this. You can do `jj merge` in a similar way to `git merge`, or you can do a rebase workflow.
- Manjuuu 3y ago
  > You would expect the push to fail in the normal way, as if you had manually done the rebase, because your commit history may have diverged. That being said, I don't think this happens much in practice: the automatic rebases are typically for explicit history-rewriting operations that users tend to only do on their local work. If a user prefers to use a "no-rewriting" workflow, then they can certainly do so by simply not issuing the history-rewriting commands. Yeah, most of those rebases happen in the working copy or inside the anonymous branch. > I'm not sure what you mean by this. You can do `jj merge` in a similar way to `git merge`, or you can do a rebase workflow. I just meant merging a feature branch back to its parent, jj merge exists but it's not obvious which revisions you are supposed to pass to it and jj log doesn't even seem to be able to update the HEAD for the parent branch. It should be an easy operation but it's not, clearly not the suggested workflow (or at least, not documented from what I've read).

miah_ 3y ago

Oh its from Google? Eh. Pass. It will either be killed in 5 years, or be pitted against Git in an attempt to take over the community.

mrd3v0 3y ago
The "disclaimer" is quite interesting. Starts off with "this is not a Google product" and ends it with the fact that it is indeed their full-time project at Google. I wish these well-intentioned Googlers realise what they are doing.
mrd3v0 3y ago
Oh, and you might be interested in https://radicle.xyz/ https://radicle.xyz/. I tried it a while ago, was stable and has nice aesthetics to it as a bonus.

Groxx 3y ago

>safe replication via rsync, Dropbox, or distributed file system Neat. I've been leaning more and more towards systems that are dumb-sync-friendly because I can throw them anywhere with anything and they just work. Always glad to see new things doing this!

snthpy 3y ago
Can someone say more about this? I've heard of this issue before but haven't experienced it myself. How does it arise, I.e. what's the race condition between git and rsync/Dropbox/... that causes problems?
- Groxx 3y ago
  Git mutates files to do many of its normal operations. Dumb-syncing without being perfectly up to date before you disconnect and switch to another machine and start making more changes means you risk conflicts (new conflict-named files in Dropbox, silently clobbered changes in many, etc), and git has essentially no way to notice this and warn you about what happened or recover what you lost. So you do your stuff, later discover the sync error when you reconnect, and now you have to choose losing data or understanding git's plumbing and raw data well enough to save both by hand. --- For example, branches. From what I can tell (I'm moderately confident here, but definitely not 100%): Git stores branches as a file at .git/refs/heads/branch-name which contains the current commit SHA. When you make a new commit in that branch, it modifies the file's contents to contain the new SHA. Syncing a conflicting change here means... well lots of possibilities. Maybe one write silently wins and the other SHA gets silently garbage collected eventually, maybe there's now a new branch with a conflicty name, maybe you have a broken file because it contains a `diff` conflict and it has <<<===>>> markers, maybe demons erupt from your nostrils. Jujutsu stores branches as a folder at some/path/branch-name/. The current head of the branch is a file in that folder with the SHA as its filename (the file is empty), giving you some/path/branch/c0ffee . If you sync changes from somewhere else due to concurrent changes to your clone, it either agrees and there's no harm, or it becomes a new file in that folder, some/path/branch/00f . Your local tool doesn't know which is correct, but it can tell that a conflict occurred, and both actions' results are still available. --- That's a thing you have to design carefully around, so it's completely understandable that it's not the default. But one of the benefits is that it means you don't need special protocols to exchange data, so tons of things simply work correctly without further effort. Git has to use lock files to protect its internals, and they have numerous issues and are completely useless in some situations (e.g. NFS, Dropbox). Jujutsu simply doesn't need them, and works safely regardless of your system or usage patterns (for this at least, dunno about everything). All this^ is why I pay to store my git repos in a git host rather than simply using my own backup systems (and why I don't have two remote backups). And it's why I avoid SQLite for much of my heavy-use personal backed-up stuff - it makes one large file that mutates, so fully syncing is a MUST before making any changes. Same with keepass - one large mutating database (but it has pretty good database merging built in, so the dozen or so conflict files I've gained are easy to resolve). There are pros and cons to splitting things up into a million files of course, but I run into sync issues pretty regularly so that's the pain I feel most keenly.

9dev 3y ago

I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit tags - everything at once, with keyboard shortcuts. Apparently, I'm in the minority here (also considering all the talk about git being such an essential skill that real programmers can issue commands blindfold). Why is that?

calvinmorrison 3y ago
Because I have two types of people who understand git on my team. People who use the CLI and people who don't understand git and just start clicking buttons
- Double_a_92 3y ago
  You forgot the people that only know: git commit -a -m "foobar" and think that's better than using a GUI to easily make clean commits.
  - calvinmorrison 3y ago
    If I could enforce one thing, it would be to REQUIRE partial commits for everything from an UI. I can't tell you the amount of commits I have seen that need to be cleaned up from spare debugging statements to vendor files to things that need to be added into the git ignore. The other thing would be to make sure people understand what things like 'squash' and 'rebase' to and how they effect the tree. Also to explain if you have multiple features, please don't work on it all on the same branch unless you have too. (This is a internal workflow, not really related to git but how we handle merges)... Yeah, a UI could be just fine for an experienced git user. In my experience though, experienced git users don't use it though, so it's a moot point.
    - 3y ago

dilap 3y ago

Extremely cool looking project which I would love to try, alas I am blocked by the lack of git-lfs support, for now https://github.com/martinvonz/jj/issues/80 https://github.com/martinvonz/jj/issues/80

Double_a_92 3y ago

I never understand such projects... How is git hard, especially compared to the complexity of most things that you would even commit to your git repository?

kuchenbecker 3y ago
Working on large complex projects the main branch will have dozens or hundreds of commits per day pushed continuously. The value is a consistent and linear commit history moving from known-state to known state. Facebook version control system built on mercurial is the best I've used. One of the huge benefits of the rebase based workflow is commits can be reordered and land as they pass tests rather than a single linear commit history.
- Double_a_92 3y ago
  You all work on one shared main branch, without any feature branches? Isn't it horrible to have other people half-finished code in the code that you are trying to work with?
  - kuchenbecker 3y ago
    Work in whatever branch you want, but if you want to merge to main and deploy it better be a stack of PRs that merge cleanly and don't expect others to wait or serialize on your change.

ChrisArchitect 3y ago

Some more discussion a year ago: https://news.ycombinator.com/item?id=30398662 https://news.ycombinator.com/item?id=30398662 Anything new in the project?

glencbz 3y ago

I've been using jj daily for close to a year and without a doubt, it blows the Git UX out of the water. I'm very particular about breaking up my changes into atomic commits, so a killer feature for me is automatic rebasing. Since conflicts can be recorded in commits, you never have to stop a rebase to fix conflicts like you do in Git and Mercurial - history operations work exactly the way a human would expect. Modify a commit? Delete it altogether? jj just automatically rebases all of the descendants for you (and yes, it handles multiple children like Mercurial evolve and unlike Git rebase). On top of this is a great set of primitives for manipulating commit history - `jj move|restore` to move|copy changes from one commit to another, `jj split` to break up commits, `jj rebase` to move commits around. _Everything_ is inside commit history (no "worktree", no "index"), so one set of commands and flags will do everything you want. The operation log is also incredible. Most operations can be undone with zero problems. Compare that to Git, where your best hope to fix a bad rebase/commit --amend is to scrounge around the reflog for the right commits and manually fixing up your refs. The biggest pain points for me are: - Automatic working copy commit sometimes tries to commit things I don't want. Usually .gitignore has things covered, but sometimes moving files around and rebasing commits breaks things. Fixing up broken commits with `jj split|restore` is pretty easy though. - No rename detection. jj doesn't handle merges as elegantly as Git. jj devs are thinking about this, but haven't quite cracked it. I'm not sure how long that will take.

predictabl3 3y ago

I'm thrilled to see the comments here. Jujube is a gem, an absolute gem. Ive never felt so empowered or fearless to make changes in a git repo, and never more confident that it would be really hard to lose work, unlike with git.

kccqzy 3y ago

Has anyone tried both this and Sapling? https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ https://engineering.fb.com/2022/11/15/open-source/sapling-so... Both of these are on my TODO lists but haven't had time to try them yet.

arxanas 3y ago
Check out https://github.com/martinvonz/jj/blob/main/docs/sapling-comparison.md https://github.com/martinvonz/jj/blob/main/docs/sapling-comp... In my opinion: - Sapling is much more mature/full-featured at this point. - Jujutsu improves source control workflows in a more principled way. - Jujutsu currently supports colocation with a Git repo, while Sapling requires that the Git repo be kept separately.

bedros 3y ago

what's the advantage of native backend compared to git repo backend?

arxanas 3y ago
> At this time, there's practically no reason to use the native backend. The backend exists mainly to make sure that it's possible to eventually add functionality that cannot easily be added to the Git backend. From the README, no advantage for now.

pyrelight 3y ago

Why/how did Git's UX become so bad?

KingMob 3y ago
Torvalds is not a UX person. If the creator is indifferent, you get a slew of commands and flags that map to the data structures and idiosyncrasies of the creator, rather than anything presenting a cohesive API to the outside world.

eviks 3y ago

Is there any good GUI client supporting this?

arxanas 3y ago
One of our Discord members had a prototype implementing support in IntelliJ if you want to try that. Other than that, I'm not aware of any jj GUI clients. However, you can use jj directly in Git repositories with the colocated mode and then continue using your preferred Git GUI client. (Obviously, you miss out on the jj-only features.)
- eviks 3y ago
  Thanks, maybe will try the co-located mode since I only use cli git for some operations not covered by GUI, and git cli UI is atrocious

rcme 3y ago

This seems like a really unnecessary amount of overhead. With build times often taking multiple minutes, being able to multi-task is essential. I often work on two things at once. That seems difficult / impossible with this.

arxanas 3y ago
What does the version control system have to do with build times and multi-tasking? I use jj in repositories with long builds, but I don't see what it has to do with that.
- rcme 3y ago
  Every jj command creates a commit. So if you have two unrelated pieces of work you need to split all the commits created.
  - arxanas 3y ago
    I see that the README is unclear or even misleading on this point. How it works is that, upon each command, the commit corresponding to the working copy is updated in a similar way as `git commit --amend`. You will typically only have one "working copy commit", which corresponds to "unstaged changes" in Git. The difference is that instead of using special-purpose commands like `git add` to interact with the staging area, you instead use the same set of commands that you would use to manipulate other commits. (There is a `jj commit` convenience command to model the common case of adding a commit message to the working copy commit and then creating a new working copy commit on top of it.)

trowaway344988 3y ago

What sourcery is that? It highlights the first character(s) of the hash! Does [git log] have that? I think too much hash looks noisy. All I could find was: $ git rev-parse --short=4 HEAD 8f60

frizlab 3y ago

> I (Martin von Zweigbergk) have almost exclusively used `jj` to develop the project itself since early January 2021. I haven't had to re-clone from source (I don't think I've even had to restore from backup). WTF?? Me neither on none of my git project. Ever. So what? I’m a git genius?? The truth is I don’t even understand how one can reach a point where re-cloning a (git) repo is needed: git can always reset --hard and it has never ever failed for me, even during complicated interactive rebase and co.