Live data from Hacker News

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

drewdevault.com

21–30 of 50 posts

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

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

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

#22
post #11
post #9

Earlier quoted context omitted.

> 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 mul…

Things like difftastic work perfectly fine with git https://difftastic.wilfred.me.uk/

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.

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

#23

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), bu…

‘jj split`isn't a workaround but their version of `git add -p`. The intent is to make the Index unspecial to make it easier to work with and not to get rid of it.

If there are usability gaps between the jj's active commit and git's index, then they should be reported.

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

#24
post #7

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!

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

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

#25
post #22
post #11

Earlier quoted context omitted.

Things like difftastic work perfectly fine with git https://difftastic.wilfred.me.uk/

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 refactore…

Store ASTs in git instead of text, "reconstruct" the text when displaying to the developer and roundtrip.

Add some execution context and annotations to the AST and you could even do "git blame" in your debugger.

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

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

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

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

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

#29

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), bu…

I do that as well. Right now I keep a pre-commit script that prevents me from committing those by mistake but I would really like for git to have some kind of .gitignore for patterns in a line. Maybe a weekend project to tackle one day.

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

#30

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.

Are there new ideas possible? If so are they better? Those are open questions.

There are old ideas about versions that git is bad at though, what we need is something with the good parts of git while also adding those old ideas that are not in git.

I'm still bummed mercurial lost to git - mercural had its problems but git is so bad at branching people have just concluding branching is a bad idea which is just wrong if you ever used mercurial branches. Those who have used other version control systems likely have their own list of features they miss.

Post reply on HN