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

Defeating Git Rigour Fatigue with Jujutsu

ikesau.co

Post reply on HN
Print view View original

21–30 of 193 posts

Re: Defeating Git Rigour Fatigue with Jujutsu

#21

Post by aggregator-ios »

codemog wrote: post #16

[flagged]

This is my take on it too. And I built BetterGit (https://www.satishmaha.com/BetterGit/) before agent capabilities became widespread. A lot of things in Git and existing GUIs are just cumbersome, and my app makes it better to handle the most common tasks and makes them easier. It's really meant for newcomers to Git.

BUT! You can simply ask an agent to commit every meaningful block of work. Or just ask any agent to create a JIRA ticket and start work on that named branch. Or ask it to create work trees and create a PR. Life has gotten much easier without having to fight the command line or confusing GUI UX.

Re: Defeating Git Rigour Fatigue with Jujutsu

#23

Post by einpoklum »

> For large features, I find this workflow far easier than having to maintain strict git rigour for the lifecycle of the feature's development.

I don't know about all that. All sorts of ex-post-facto automated cut-up-and-splice commits sounds to me like a recipe for an every larger mess. I say maintain git rigor, always. Now, you could say "You only say that because you know git rather than jujutsu" or "if you use git absorb more you'll get it", and theoretically you might be right, but... meh, I kind of doubt it.

Re: Defeating Git Rigour Fatigue with Jujutsu

#24

Post by raincole »

9029 wrote: post #13
diath wrote: post #3

So... git rebase -i?

I'd recommend reading the post, it's not that long

As someone who doesn't know jj and read this article, it does sound like `git rebase -i` to me. I'm sure that if I actually spent time learning jj I'd know the difference though.

Re: Defeating Git Rigour Fatigue with Jujutsu

#25

Post by ahepp »

nomel wrote: post #6
diath wrote: post #3

So... git rebase -i?

Definitely not. Switch to a previous commit, make edits, changes propagate into the future commits (including into a git repo if you wish [1]) Jj is not git and is not a git tool, it just (thankfully) uses git as a backend, so you can still carry on with the rest of the world. [1] https://news.ycombinator.com/item?id=47765759

> Switch to a previous commit, make edits, changes propagate into the future commits

In what way is that different from using `git rebase -i` to edit a commit?

Re: Defeating Git Rigour Fatigue with Jujutsu

#26

Post by fragmede »

The elephant in the room is that I haven't had to do something complicated and manual in git by hand in a long while. I'm using AI to generate code, and further, having it commit to git and pushing and pulling and managing branches and merging for me. So for people new to software development, they can also just ask AI to deal with git, which papers over the harder parts of its UX.

Re: Defeating Git Rigour Fatigue with Jujutsu

#27

Post by idoubtit »

diath wrote: post #3

So... git rebase -i?

No, more like:

    git rebase -i
    # squash all the commits (e.g. in vim with ctrl-v)
    git reset HEAD^
    git add -p
    # interactively pickup the RED hunks
    git ci -m RED
The main difference to jj is that the RED commit is created later with git.

Re: Defeating Git Rigour Fatigue with Jujutsu

#28

Post by ikesau »

winterqt wrote: post #9

> `absorb` assigns the changes based on whichever previous commit most recently touched those files, which sometimes doesn't actually correspond to which commit should own these particular changes. I’m pretty sure `jj absorb` (and its predecessors, `git-absorb` [0] and `hg absorb`) are smarter than this, instead looking at the actual diffs. [0]: https://github.com/tummychow/git-absorb

Ah yeah, you're right, that's a misrepresentation on my part - it's based on lines, not the file:

> [absorb] splits changes in the source revision and moves each change to the closest mutable ancestor where the corresponding lines were modified last. If the destination revision cannot be determined unambiguously, the change will be left in the source revision.

I use absorb fairly often, fwiw. It's great for when I want to make a patch to a commit that will easily absorb into its right place. And I also, sometimes, prefer the more intentional approach where I decide exactly where each hunk will go.

Re: Defeating Git Rigour Fatigue with Jujutsu

#29

Post by skydhash »

incognito124 wrote: post #15
nomel wrote: post #7

Earlier quoted context omitted.

I think jj will never gain momentum because people only have a git mental model at this point, so won't be able to effectively reason about jj.

I spoke about this before, but jj has the Blub Paradox problem, from the pg's essay Beating the Averages ( https://paulgraham.com/avg.html ). Yes, you can do most commit manipulations with git just like with jj. But, users of jj know they're "looking down the power continuum" (to reuse pg's terminology) when they look at git, whereas git users cannot fathom what's exactly the deal with jj. Unfortunately, the only way…

> Unfortunately, the only way to get it is to spend a week with it, with an open mind

We do get it. But have you ever thought that git inflexible nature and full control is what some people people like?

Having three different state for your work (working tree, staging, and committed) is nice for reviewing code. Picking lines and chunk give me an additional mental state to think about the design of the code.

And once upon a time, I preferred history log like the one in the article. But this days (mostly inspired by mailing list development style) I wants the commit in my main log to be either features or bug fixes. Everything else is “wip”, which I will squash. It makes it easier when rewriting history, cherry picking, or just browsing the log.

Re: Defeating Git Rigour Fatigue with Jujutsu

#30

Post by jolux »

skydhash wrote: post #29
incognito124 wrote: post #15

Earlier quoted context omitted.

I spoke about this before, but jj has the Blub Paradox problem, from the pg's essay Beating the Averages ( https://paulgraham.com/avg.html ). Yes, you can do most commit manipulations with git just like with jj. But, users of jj know they're "looking down the power continuum" (to reuse pg's terminology) when they look at git, whereas git users cannot fathom what's exactly the deal with jj. Unfortunately, the only way…

> Unfortunately, the only way to get it is to spend a week with it, with an open mind We do get it. But have you ever thought that git inflexible nature and full control is what some people people like? Having three different state for your work (working tree, staging, and committed) is nice for reviewing code. Picking lines and chunk give me an additional mental state to think about the design of the code. And once…

There’s nothing stopping you from using separate changes to emulate the staging area if you want.
Post reply on HN