4 ms·

I'm daily driving Jujutsu, and maybe you should too

84 points by surprisetalk 2y ago

pabs3 2y ago
The post got deleted, but it got saved to IA: https://web.archive.org/web/20241212125937/https://drewdevault.com/2024/12/10/2024-12-10-Daily-driving-jujutsu.html https://web.archive.org/web/20241212125937/https://drewdevau...
not_your_vase 2y ago
Why is there no git-light VCS, with only the top 5-8 commands available? Push, fetch, commit, merge, rebase, branch, init... maybe I forget 1 or 2. I have to think extremely hard what command I used intentionally in the past 10 years (sometimes I used some arcane commands, only to fix some problems that was caused by some other arcane commands)
- snvzz 2y ago
  There's Openbsd's got[0]. 0. https://gameoftrees.org/index.html https://gameoftrees.org/index.html
  - not_your_vase 2y ago
    Almost... but not what I'm looking for. I'm looking for something without actual git. I can also just ignore most of the ugly commands of git, but I'm thinking of something that doesn't make me think of what commands are worth remembering. I'm looking for "simple code versioning for dummies, that you can't break even if you tried hard"
    - ramses0 2y ago
      Fossil!?! https://fossil-scm.org/home/doc/trunk/www/quickstart.wiki https://fossil-scm.org/home/doc/trunk/www/quickstart.wiki
    - delinom 2y ago
      Simplicity is in the eye of the beholder but Pijul claims to be "easy to learn and use". https://pijul.org/ https://pijul.org/
    - thunderbong 2y ago
      Like the sibling comment mentioned, what you're looking for is fossil [0]. Fossil was created by Richard Hipp, who's also the creator of SQLite. Fossil as a version management system gets completely out of the way. In all the years over used Fossil, I've rarely had to use more than a few commands and have never had to understand any underlying concepts, let alone trying to figure out how to use the commands. Additionally, fossil also comes with a wiki and a bug tracker, which is a bonus. [0]: https://fossil-scm.org/ https://fossil-scm.org/
- elric 2y ago
  Surely you can just use git and limit yourself to the commands you're comfortable with?
  - brabel 2y ago
    I've used git effectively and painlessly for many years, and pretty much all commands I ever use are commit, pull, push, checkout, merge and rebase. :) And diff if for whatever reason my IDE is not open already.
- cardanome 2y ago
  Not exactly what you asked for but if you are an emacs user, magit will make using git so much more pleasant. https://magit.vc/ https://magit.vc/ Generally most IDEs will help you out with basic git tasks without even needing to know commands. There also dedicated GUIs for git. Though for full time devs just learning how to use plain git isn't that hard. I very rarely have to look up git commands these days. You can limit yourself to the basic commands first.
  - goku12 2y ago
    Magit is more like a keyboard shortcut for those who already know their way around the git CLI. The direct mapping of CLI to short key sequences and the coherent visual feedback are the qualities that make magit so popular. I don't think someone who finds the CLI unpleasant will find magit to be any better.
- goku12 2y ago
  I think you're going about it in the wrong direction. Instead of learning what each command does, try learning what operations are possible (eg: move the current branch-ref to another commit, transplant a bunch of commits from one commit to another, etc). You just associate the commands to those operations through repeated use - no forced learning necessary. Recollecting the command is just a manpage away even for rarely performed operations. That makes it easy to learn not just the subcommands, but complex flag combinations as well. This method also lends well to problem solving. You don't look at a repo and immediately think 'what commands will I use?'. You start with the problem. Then you formulate a solution as a sequence of operations that you know. You may be able to solve a problem with more operations even if you know fewer operations. Finally, convert each operation into a command and execute them. Even the pro-git book is structured this way.
null_investor 2y ago
I don't like it, I was expecting something new that replaces Git with a new idea about versioning. I can already work extremely fast in Git by using bash aliases and my workflow. This might be useful for those starting out.
- arkh 2y ago
  > replaces Git with a new idea about versioning With the advent of LSP I feel like we're almost to a point where you could version structures and not code. Like being able to follow how some class / method got cut in multiple pieces during a refactoring round. Or maybe we need something more than plaintext to store code and the meta data around it before we can get to this point. I'm sure it has been already done multiple times in different ecosystems but there must be a way to standardize the information about code and use it in IDE and versioning tools.
  - zokier 2y ago
    Things like difftastic work perfectly fine with git https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/
    - arkh 2y ago
      Let's say I have a methodA somewhere in my code. I decide to rename it and add a parameter: my IDE knows what I'm doing as it can change the new name everywhere the method is used. My versioning tool not so much: it can tell me some lines changed but it does not expose the fact "methodA has been renamed to superMethodB", that's something the user has to put in a commit file. Add a moment when this method is refactored as 2 new methods and it starts being harder to follow in diff files. Most code forges already link commits to tickets: why not be able to directly link code constructs changes to tickets to telemetry artifacts? Mostly hidden through the IDE "task" management but all present in whatever ends in versioning. You could get git blame on steroids.
      - rswail 2y ago
k__ 2y ago
Going from changing the code and then describing it to describing your planned change and then implementing it is a good idea. Now, I just need some GUI indicator or CLI prompt to ensure I don't lose track and I'm good to go!
- goku12 2y ago
  That sounds exactly like what https://stacked-git.github.io/ https://stacked-git.github.io/ is used for.
do_not_redeem 2y ago
The one thing keeping me from switching fulltime is the friction of keeping unstaged changes in the repo. It's pretty common for me to have some throwaway lines like DEBUG = true or setLogLevel(LogLevel.VERBOSE) that are "permanent" in my dev environment but I never want to commit. With git I can just `git add --patch` and skip over these at commit time (which I like, since I review my own code as I'm staging it), but jj doesn't have the index and pushes you to commit all changes by default. I know there are workarounds like `jj split` but it ended up being more work than git, where I can just not add those changes in the first place.
- OskarS 2y ago
  The ”staging” concept in git is something that I know really bugs a lot of people, especially beginners with git. Like ”I just want to commit, why is there this extra step?”, but I totally agree with you. Maybe it’s Stockholm Syndrome, but I really like that there’s an extra “look through your changes” procedure before committing, exactly for reasons like this.
  - wbkang 2y ago
    It sounds like Stockholm to me ;) I don't think you _need_ the index to make partial commit work. I've used Mercurial first so I know "hg commit -i" exists. Even if the staging concept is clear to someone, git cli terminology _is_ objectively very confusing and there are many articles written about it already (e.g., do I "add" to index? Is the index also referred as cached/Staged? Mixing different verbs and nouns everywhere). Are they all the same?) I just wrote this to say it is not a necessary part of making a tool as powerful as git - Mercurial shows an example of a similar tool with a less confusing CLI. Of course, git won so I just live with it. I enjoy teaching git new devs because once you explain the confusing terminology up front, they understand it faster.
  - pragma_x 2y ago
    > an extra “look through your changes” procedure A lot of the time, when I do my best to blow past that step, I forget to add new files to the commit. I wind up with all this needless CI activity on push, publish a whole PR for others to see, and generally waste everyone's time. Git's workflow really is based on this whole corpus of shared VCS experience, and it shows. The downside to all that is that Git is _everyone's_ workflow, and nobody's at the same time. It's a compromise, and the tool does expose everyone to all the small little steps that are a part of that bigger experience. That said, if there was a more succinct workflow that was smart enough to flag simple mistakes for me, I would welcome it.
xyzsparetimexyz 2y ago
I'm happy enough with git most of the time. But the porcelain still sucks for a few things that feel like the should be basic and it doesn't feel like it's getting better or that any new tools have been written that fix the gaps for me. One problem I've had recently is that I've wanted to store a large JSON file on GitHub (that's, importantly, modified slightly each commit), but with indentation it's over 100mb so GitHub doesn't allow it. I can strip out the indentation and that takes it down to 60mb or so, but the large objects are still in git history so they get rejected, so evidently I need to rewrite the git history. Unfortunately, if you just take an old commit, strip the indentation from the JSON and try to rebase all the other commits on top of that, it'll fail as git treats each commit as a patch and the patches to the unindented JSON don't make sense. What I really want is to for git to treat each commit as a repository state, so that removing indentation from the state at commit A means that the patch for commit B adds all the indentation, and then I can just write a loop that rewrites each commit state. This seems like something that there should be better tooling for, I mean `git filter-branch` exists but I don't think it works for this usecase. Edit: Here’s what chatgpt suggests (for rust code): ```python import os import subprocess def reformat_file(repo, commit, file_name): # Check if the file exists in this commit if os.path.isfile(file_name): # Run cargo fmt to format the file subprocess.run(["cargo", "fmt"], check=True) # Stage the changes subprocess.run(["git", "add", file_name], check=True) def main(repo): file_to_fix = "path/to/your/file.rs" repo.filter_commit(reformat_file, file_to_fix) ``` And running with `git filter-repo --path path/to/your/file.rs --replace-callback reformat.py`. Ridiculous complicated.
- SkySkimmer 2y ago
  >What I really want is to for git to treat each commit as a repository state, so that removing indentation from the state at commit A means that the patch for commit B adds all the indentation `git rebase -X theirs` seems like it should be close, but commit B will only override conflicting chunks (so a change from A which doesn't conflict with B will persist, this shouldn't be a problem for your use case)
- chrishill89 2y ago
  You want to rewrite each commit snapshot in isolation? Like fix the formatting for each? Sounds like `git test fix` from git-branchless. https://blog.waleedkhan.name/formatting-a-commit-stack/ https://blog.waleedkhan.name/formatting-a-commit-stack/
epage 2y ago
> I would have contributed patches to address these shortcomings if it were not for my third criticism, which addresses the elephant in the room: Jujutsu is a Google employee’s “20% project”, and thus all contributors are required to sign the Google CLA to participate. I refuse to sign any such thing and so should you. I have raised the issue on GitHub but it hasn’t attracted any sort of official response. Unsure why he hasn't gotten a response but last I heard on this is they are focusing on defining their google-independent governance before which will give them room to address CLA's.
deleted 2y ago
[deleted]
deltaburnt 2y ago
The biggest feature gap I noticed was the lack of hooks. Using Gerrit requires a commit hook to insert the change ID. jj's docs mention this specific use case, but their workaround (using a custom commit msg editor command that wraps vim) feels hacky. Didn't bother looking further into it, not sure if this is a technical or ideological choice. Otherwise it reminded me about all the best parts of mercurial and git branchless. Pretty excited to get Fig-esque features in my external projects.
- kardianos 2y ago
  I also use gerrit, and one repo uses large files. Looking at the roadmap ( https://martinvonz.github.io/jj/latest/roadmap/ https://martinvonz.github.io/jj/latest/roadmap/ ) they are aware of both these things, but aren't done. That being said, it looks like jj pragmatically addresses many of the issues with git.
DaSHacka 2y ago
Obligatory: https://dmpwn.info/ https://dmpwn.info/
porridgeraisin 2y ago
I use the "stackless" stacked PR git workflow mentioned in the article. I also add a bit of niceness to it so I don't have to remember the commit IDs: So git has a notes feature, this is a simple note attached to a commit. It's intended for adding extra context to commit messages without changing the commit hash. Then there is a gitconfig for having these notes _follow_ the commit through rewrites such as rebases, squashes, amends, etc,. All this together means that you write the branch name that you want in the note, use the git notes commands to two-way map this to the commit. Wrap this all in a git alias and it's golden.
SuperSandro2000 2y ago
Branch names that are not just a keyboard smash maybe?
simonmic 2y ago
PSA for those interested in trying jujutsu, but not ready to have it auto-track all files in working copy: you can disable that in ~/.jjconfig.toml: [snapshot] auto-track = "none()"

84 points by surprisetalk 2y ago

The post got deleted, but it got saved to IA: https://web.archive.org/web/20241212125937/https://drewdevault.com/2024/12/10/2024-12-10-Daily-driving-jujutsu.html https://web.archive.org/web/20241212125937/https://drewdevau...

not_your_vase 2y ago

Why is there no git-light VCS, with only the top 5-8 commands available? Push, fetch, commit, merge, rebase, branch, init... maybe I forget 1 or 2. I have to think extremely hard what command I used intentionally in the past 10 years (sometimes I used some arcane commands, only to fix some problems that was caused by some other arcane commands)

snvzz 2y ago
There's Openbsd's got[0]. 0. https://gameoftrees.org/index.html https://gameoftrees.org/index.html
- not_your_vase 2y ago
  Almost... but not what I'm looking for. I'm looking for something without actual git. I can also just ignore most of the ugly commands of git, but I'm thinking of something that doesn't make me think of what commands are worth remembering. I'm looking for "simple code versioning for dummies, that you can't break even if you tried hard"
  - ramses0 2y ago
    Fossil!?! https://fossil-scm.org/home/doc/trunk/www/quickstart.wiki https://fossil-scm.org/home/doc/trunk/www/quickstart.wiki
  - delinom 2y ago
    Simplicity is in the eye of the beholder but Pijul claims to be "easy to learn and use". https://pijul.org/ https://pijul.org/
  - thunderbong 2y ago
    Like the sibling comment mentioned, what you're looking for is fossil [0]. Fossil was created by Richard Hipp, who's also the creator of SQLite. Fossil as a version management system gets completely out of the way. In all the years over used Fossil, I've rarely had to use more than a few commands and have never had to understand any underlying concepts, let alone trying to figure out how to use the commands. Additionally, fossil also comes with a wiki and a bug tracker, which is a bonus. [0]: https://fossil-scm.org/ https://fossil-scm.org/
elric 2y ago
Surely you can just use git and limit yourself to the commands you're comfortable with?
- brabel 2y ago
  I've used git effectively and painlessly for many years, and pretty much all commands I ever use are commit, pull, push, checkout, merge and rebase. :) And diff if for whatever reason my IDE is not open already.
cardanome 2y ago
Not exactly what you asked for but if you are an emacs user, magit will make using git so much more pleasant. https://magit.vc/ https://magit.vc/ Generally most IDEs will help you out with basic git tasks without even needing to know commands. There also dedicated GUIs for git. Though for full time devs just learning how to use plain git isn't that hard. I very rarely have to look up git commands these days. You can limit yourself to the basic commands first.
- goku12 2y ago
  Magit is more like a keyboard shortcut for those who already know their way around the git CLI. The direct mapping of CLI to short key sequences and the coherent visual feedback are the qualities that make magit so popular. I don't think someone who finds the CLI unpleasant will find magit to be any better.
goku12 2y ago
I think you're going about it in the wrong direction. Instead of learning what each command does, try learning what operations are possible (eg: move the current branch-ref to another commit, transplant a bunch of commits from one commit to another, etc). You just associate the commands to those operations through repeated use - no forced learning necessary. Recollecting the command is just a manpage away even for rarely performed operations. That makes it easy to learn not just the subcommands, but complex flag combinations as well. This method also lends well to problem solving. You don't look at a repo and immediately think 'what commands will I use?'. You start with the problem. Then you formulate a solution as a sequence of operations that you know. You may be able to solve a problem with more operations even if you know fewer operations. Finally, convert each operation into a command and execute them. Even the pro-git book is structured this way.

null_investor 2y ago

I don't like it, I was expecting something new that replaces Git with a new idea about versioning. I can already work extremely fast in Git by using bash aliases and my workflow. This might be useful for those starting out.

arkh 2y ago
> replaces Git with a new idea about versioning With the advent of LSP I feel like we're almost to a point where you could version structures and not code. Like being able to follow how some class / method got cut in multiple pieces during a refactoring round. Or maybe we need something more than plaintext to store code and the meta data around it before we can get to this point. I'm sure it has been already done multiple times in different ecosystems but there must be a way to standardize the information about code and use it in IDE and versioning tools.
- zokier 2y ago
  Things like difftastic work perfectly fine with git https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/
  - arkh 2y ago
    Let's say I have a methodA somewhere in my code. I decide to rename it and add a parameter: my IDE knows what I'm doing as it can change the new name everywhere the method is used. My versioning tool not so much: it can tell me some lines changed but it does not expose the fact "methodA has been renamed to superMethodB", that's something the user has to put in a commit file. Add a moment when this method is refactored as 2 new methods and it starts being harder to follow in diff files. Most code forges already link commits to tickets: why not be able to directly link code constructs changes to tickets to telemetry artifacts? Mostly hidden through the IDE "task" management but all present in whatever ends in versioning. You could get git blame on steroids.
    - rswail 2y ago

k__ 2y ago

Going from changing the code and then describing it to describing your planned change and then implementing it is a good idea. Now, I just need some GUI indicator or CLI prompt to ensure I don't lose track and I'm good to go!

goku12 2y ago
That sounds exactly like what https://stacked-git.github.io/ https://stacked-git.github.io/ is used for.

do_not_redeem 2y ago

The one thing keeping me from switching fulltime is the friction of keeping unstaged changes in the repo. It's pretty common for me to have some throwaway lines like DEBUG = true or setLogLevel(LogLevel.VERBOSE) that are "permanent" in my dev environment but I never want to commit. With git I can just `git add --patch` and skip over these at commit time (which I like, since I review my own code as I'm staging it), but jj doesn't have the index and pushes you to commit all changes by default. I know there are workarounds like `jj split` but it ended up being more work than git, where I can just not add those changes in the first place.

OskarS 2y ago
The ”staging” concept in git is something that I know really bugs a lot of people, especially beginners with git. Like ”I just want to commit, why is there this extra step?”, but I totally agree with you. Maybe it’s Stockholm Syndrome, but I really like that there’s an extra “look through your changes” procedure before committing, exactly for reasons like this.
- wbkang 2y ago
  It sounds like Stockholm to me ;) I don't think you _need_ the index to make partial commit work. I've used Mercurial first so I know "hg commit -i" exists. Even if the staging concept is clear to someone, git cli terminology _is_ objectively very confusing and there are many articles written about it already (e.g., do I "add" to index? Is the index also referred as cached/Staged? Mixing different verbs and nouns everywhere). Are they all the same?) I just wrote this to say it is not a necessary part of making a tool as powerful as git - Mercurial shows an example of a similar tool with a less confusing CLI. Of course, git won so I just live with it. I enjoy teaching git new devs because once you explain the confusing terminology up front, they understand it faster.
- pragma_x 2y ago
  > an extra “look through your changes” procedure A lot of the time, when I do my best to blow past that step, I forget to add new files to the commit. I wind up with all this needless CI activity on push, publish a whole PR for others to see, and generally waste everyone's time. Git's workflow really is based on this whole corpus of shared VCS experience, and it shows. The downside to all that is that Git is _everyone's_ workflow, and nobody's at the same time. It's a compromise, and the tool does expose everyone to all the small little steps that are a part of that bigger experience. That said, if there was a more succinct workflow that was smart enough to flag simple mistakes for me, I would welcome it.

xyzsparetimexyz 2y ago

I'm happy enough with git most of the time. But the porcelain still sucks for a few things that feel like the should be basic and it doesn't feel like it's getting better or that any new tools have been written that fix the gaps for me. One problem I've had recently is that I've wanted to store a large JSON file on GitHub (that's, importantly, modified slightly each commit), but with indentation it's over 100mb so GitHub doesn't allow it. I can strip out the indentation and that takes it down to 60mb or so, but the large objects are still in git history so they get rejected, so evidently I need to rewrite the git history. Unfortunately, if you just take an old commit, strip the indentation from the JSON and try to rebase all the other commits on top of that, it'll fail as git treats each commit as a patch and the patches to the unindented JSON don't make sense. What I really want is to for git to treat each commit as a repository state, so that removing indentation from the state at commit A means that the patch for commit B adds all the indentation, and then I can just write a loop that rewrites each commit state. This seems like something that there should be better tooling for, I mean `git filter-branch` exists but I don't think it works for this usecase. Edit: Here’s what chatgpt suggests (for rust code): ```python import os import subprocess def reformat_file(repo, commit, file_name): # Check if the file exists in this commit if os.path.isfile(file_name): # Run cargo fmt to format the file subprocess.run(["cargo", "fmt"], check=True) # Stage the changes subprocess.run(["git", "add", file_name], check=True) def main(repo): file_to_fix = "path/to/your/file.rs" repo.filter_commit(reformat_file, file_to_fix) ``` And running with `git filter-repo --path path/to/your/file.rs --replace-callback reformat.py`. Ridiculous complicated.

SkySkimmer 2y ago
>What I really want is to for git to treat each commit as a repository state, so that removing indentation from the state at commit A means that the patch for commit B adds all the indentation `git rebase -X theirs` seems like it should be close, but commit B will only override conflicting chunks (so a change from A which doesn't conflict with B will persist, this shouldn't be a problem for your use case)
chrishill89 2y ago
You want to rewrite each commit snapshot in isolation? Like fix the formatting for each? Sounds like `git test fix` from git-branchless. https://blog.waleedkhan.name/formatting-a-commit-stack/ https://blog.waleedkhan.name/formatting-a-commit-stack/

epage 2y ago

> I would have contributed patches to address these shortcomings if it were not for my third criticism, which addresses the elephant in the room: Jujutsu is a Google employee’s “20% project”, and thus all contributors are required to sign the Google CLA to participate. I refuse to sign any such thing and so should you. I have raised the issue on GitHub but it hasn’t attracted any sort of official response. Unsure why he hasn't gotten a response but last I heard on this is they are focusing on defining their google-independent governance before which will give them room to address CLA's.

deleted 2y ago

[deleted]

deltaburnt 2y ago

The biggest feature gap I noticed was the lack of hooks. Using Gerrit requires a commit hook to insert the change ID. jj's docs mention this specific use case, but their workaround (using a custom commit msg editor command that wraps vim) feels hacky. Didn't bother looking further into it, not sure if this is a technical or ideological choice. Otherwise it reminded me about all the best parts of mercurial and git branchless. Pretty excited to get Fig-esque features in my external projects.

kardianos 2y ago
I also use gerrit, and one repo uses large files. Looking at the roadmap ( https://martinvonz.github.io/jj/latest/roadmap/ https://martinvonz.github.io/jj/latest/roadmap/ ) they are aware of both these things, but aren't done. That being said, it looks like jj pragmatically addresses many of the issues with git.

DaSHacka 2y ago

Obligatory: https://dmpwn.info/ https://dmpwn.info/

porridgeraisin 2y ago

I use the "stackless" stacked PR git workflow mentioned in the article. I also add a bit of niceness to it so I don't have to remember the commit IDs: So git has a notes feature, this is a simple note attached to a commit. It's intended for adding extra context to commit messages without changing the commit hash. Then there is a gitconfig for having these notes _follow_ the commit through rewrites such as rebases, squashes, amends, etc,. All this together means that you write the branch name that you want in the note, use the git notes commands to two-way map this to the commit. Wrap this all in a git alias and it's golden.

SuperSandro2000 2y ago

Branch names that are not just a keyboard smash maybe?

simonmic 2y ago

PSA for those interested in trying jujutsu, but not ready to have it auto-track all files in working copy: you can disable that in ~/.jjconfig.toml: [snapshot] auto-track = "none()"