Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

drewdevault.com

Post reply on HN
Print view View original

41–50 of 50 posts

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

#41

Post by SkySkimmer »

xyzsparetimexyz wrote: post #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 Gi…

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

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

#42

Post by [deleted] »

do_not_redeem wrote: post #13

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…

[deleted]

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

#43

Post by zokier »

rswail wrote: post #25
arkh wrote: post #22

Earlier quoted context omitted.

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.

code can be thought of as serialized ast, and you need to serialize ast somehow anyways for storage

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

#44

Post by chrishill89 »

arkh wrote: post #9
null_investor wrote: post #6

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.

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

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

This idea of storing more structured information (in the VCS or on disk) keeps coming up but I don't think it's necessary at all. The disk and the VCS can stay dumb. You can reconstruct the rich information after the fact.

It boils down to storing the right information and extracting it. Maybe you want to guard some checkpoints from bad/unstructured data. But that's just a check[1]. The serialization can be simple.

Well say you are blocked from storing bad data (according to the structure). Say you can also detect refactors like code moves (better than Git does, I guess just line moves). Again the storage can be dumb so that's fine. But you still need intentional commits; you won't get helped by a 500-line diff where all kinds of back and forth to solve three and half separate concerns are buried.

First of all you need good data in order to have something to extract. Which requires commit discipline.

[1]: And you don't get much from storing in a more rich format by itself. Just that you committed/stored syntactically correct/compilable artifacts. That's not nearly as rich as what you want. Because there are thousands of different intents (like you allude to) like refactorings -- all are valid in their own way so the structured representation can't have an opinion on it.

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

#46

Post by chrishill89 »

xyzsparetimexyz wrote: post #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 Gi…

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/

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

#47

Post by rswail »

zokier wrote: post #43
rswail wrote: post #25

Earlier quoted context omitted.

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.

code can be thought of as serialized ast, and you need to serialize ast somehow anyways for storage

Yes and no, code comes with affordances like whitespace and comment layouts that are for humans that are unnecessary excess for ASTs.

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

#48

Post by codethief »

martinvonz wrote: post #37
arkh wrote: 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…

You might find Unison interesting: https://www.unison-lang.org/docs/the-big-idea/

Also, https://scrapscript.org/

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

#49

Post by sgjennings »

do_not_redeem wrote: post #13

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…

The way I handle that with jj is to keep those changes in a commit “on the side” rather than making them “on top” of the working copy. The FAQ entry for this describes the process (https://martinvonz.github.io/jj/latest/FAQ/#how-can-i-avoid-...):

- Make a commit off main that includes these private changes

- Make a commit for the work you’re doing

- Create a merge commit on top of these two changes and work there

This works because the “DEBUG=true” change is already committed, but in a commit you never push to the remote. jj makes it easy to continually squash the work you want to keep from the merge commit into one where it belongs. And, there is a “private commits” setting you can use to prevent accidentally pushing that commit somewhere.

Post reply on HN