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

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.

> 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.

The post got deleted, but it got saved to IA:

https://web.archive.org/web/20241212125937/https://drewdevau...

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.

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!

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()"

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.

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.

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.

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)

Branch names that are not just a keyboard smash maybe?

Obligatory: https://dmpwn.info/