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

151–160 of 193 posts

Re: Defeating Git Rigour Fatigue with Jujutsu

#151

Post by skydhash »

Zizizizz wrote: post #148
regularfry wrote: post #140

So I'd have an immediate problem with the target sequence of commits here. The thing about just getting a "define types" commit is that it shows me nothing about why those types were chosen. I need to flit backwards and forwards in history to see how they hook into the later code. I lose the history of "this type was enough to get us to point A, we needed this other thing to get to point B". But flitting back and for…

I would imagine why the types were chosen could easily be explained in the commit message. The goal presumably (at least how I do it) is so that if I'm touching quite a lot of the code base, the reviewer has the _option_ of being taken through the narrative of the change like they might explain if they were talking to you. If you don't want to be told what the changes are and how they tie together, then just click on…

I work via tickets so I don’t take care of the commits in my branch (if I would there would only be one commit). So what I expect the reviewer to do is review the whole diff. I help by commenting the changes to explain the design and the implementation.

Commits on a PR branch are usually my thinking outline, not for someone else to step through.

Re: Defeating Git Rigour Fatigue with Jujutsu

#152

Post by vaylian »

Balinares wrote: post #146
vaylian wrote: post #144

> This allows reviewers to step through your pull request in small bites, with each set of changes scoped to a single aspect of the feature. Is that a frequent way of reviewing? On GitHub you get shown all changes together in the review tab. You can select individual commits for closer inspection, but where is the benefit?

A series of piecemeal self-contained changes is much easier to wrap your brain around comprehensively enough to detect logic issues. I started doing exactly this and it's been invaluable.

How does this work for you UX-wise? Do you use github? Do you and your collaborators select each commit individually inside a pull request?

Re: Defeating Git Rigour Fatigue with Jujutsu

#153

Post by LtWorf »

y1n0 wrote: post #2

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…

I've worked in places where they didn't know about git branches. They only had master.

Review was done by having someone sit next to you and scrolling through the code telling what you had changed.

Re: Defeating Git Rigour Fatigue with Jujutsu

#154

Post by luodaint »

Agentic development transforms the scope of work. Once a session is committed to having one topic from the get-go — one move, one service, one abstraction — the diff generated from such a session is atomic by construction. Committing happens at the session level, and the commitment discipline problem solved by Jujutsu does not come into play.

It is also true in reverse. Scopes set too broadly ("dark mode implementation," "auth flow fixes") lead to un-readable diffs no matter what tool you use for version control. Un-readable diff does not stem from commitment discipline; it is a scope problem.

That said, this fact does not diminish the usefulness of Jujutsu. There are valid use cases for the rebase and stacking operations. However, the discussion about commit granularity takes on a whole new context once the constraint of having readable commits is established at the scope setting stage.

Re: Defeating Git Rigour Fatigue with Jujutsu

#155

Post by Zizizizz »

skydhash wrote: post #151
Zizizizz wrote: post #148

Earlier quoted context omitted.

I would imagine why the types were chosen could easily be explained in the commit message. The goal presumably (at least how I do it) is so that if I'm touching quite a lot of the code base, the reviewer has the _option_ of being taken through the narrative of the change like they might explain if they were talking to you. If you don't want to be told what the changes are and how they tie together, then just click on…

I work via tickets so I don’t take care of the commits in my branch (if I would there would only be one commit). So what I expect the reviewer to do is review the whole diff. I help by commenting the changes to explain the design and the implementation. Commits on a PR branch are usually my thinking outline, not for someone else to step through.

That's fair enough! I think the flow will be more universally beneficial if things like this become more mainstream. https://github.github.com/gh-stack/ because then big prs aren't necessary if they can be reviewed incrementally so long as they can stand on their own.

Re: Defeating Git Rigour Fatigue with Jujutsu

#156

Post by Yokohiii »

vaylian wrote: post #144

> This allows reviewers to step through your pull request in small bites, with each set of changes scoped to a single aspect of the feature. Is that a frequent way of reviewing? On GitHub you get shown all changes together in the review tab. You can select individual commits for closer inspection, but where is the benefit?

I suspect there is some weird habit that some people even like to overengineer their git history. Maybe it improves the pixel fame ratio or something.

For me it's satire. There are reasons for varying effort in creating PRs or patches, but attempts like this never seem to reason about reality. If I have to review, I want to see the code, not a clever story hidden in the commit history.

Re: Defeating Git Rigour Fatigue with Jujutsu

#158

Post by Yokohiii »

NamlchakKhandro wrote: post #83
BobbyTables2 wrote: post #56

I don’t understand. Are there people that try to use git without ever invoking “git rebase -i” ?

Yes. almost the majority of git users do this. i would say that as an expert commenter, 99.9% of people outside of California do this.

TIL I am a minority.

Re: Defeating Git Rigour Fatigue with Jujutsu

#160

Post by em-bee »

igor47 wrote: post #117
em-bee wrote: post #102

Earlier quoted context omitted.

that doesn't make sense because when i am working on a feature, i create a branch, name the branch after the feature and then each commit has a description of what is in that commit. the feature has multiple commits, and while i carefully work out what goes in each commit i don't squash them. so with jj i could use a bookmark, ok, but having to manually update that bookmark feels wrong.

When I'm working in git, I always start work by creating a new branch with a name. Sometimes the branch becomes something different as I work and then I might rename it or more often just keep a stale name around. But in git commit descriptions come later. In jj, it's the opposite. I start with a change, and I often describe it right away. Branches (bookmarks) come at the end. You could, in jj, tag a new empty change…

that the first change in a sequence of changes is tagged with a bookmark is probably as much information as you need?

i was actually wondering about that. it might. i'll have to see it in action...

Post reply on HN