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

141–150 of 193 posts

Re: Defeating Git Rigour Fatigue with Jujutsu

#141

Post by silon42 »

gertburger wrote: post #131

I'd like to give jj another go but I found the "all files must be tracked/committed" approach to really break my workflow. I have a lot of temporary uncommitted files, which are not ignored or excluded. Some may eventually be committed but most won't. Being then forced to commit these (but only some due to file size) just gets in the way and impedes things like cross branch debugging A checkout is a working space aft…

Same here, auto-adding is a non-starter for me. Thankfully there's an option to not do it, not sure how well it works, but I'll have it enabled for the future when I try jj again.

Re: Defeating Git Rigour Fatigue with Jujutsu

#142

Post by arccy »

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 too work with worktrees (jj workspaces) and prs (requires branches). it's easier if you give up choosing the name of your branch, and instead rely on finding things by description or your workspace name.

for prs, I usually start with a single commit, so `jj git push -c` will auto create a named branch based on the change id. And i have template like the following to push to the same branch if i decided to stack commits rather than rewrite:

    branch-push   = ["util", "exec", "--", "sh", "-c", """
    name="$(jj log --no-graph --no-pager --color=never -r 'fork_point(@ | trunk())+ & fork_point(@ | trunk())..@' -T '"push-" ++ change_id.short()')"
    jj bookmark set -r @- "${name}"
    jj git push -b "${name}"
    """]
you could probably write a similar alias that used your workspace name as the branch name to push to.

and descriptions are slightly nicer than branch names, since they can be longer.

Re: Defeating Git Rigour Fatigue with Jujutsu

#143

Post by arccy »

gertburger wrote: post #131

I'd like to give jj another go but I found the "all files must be tracked/committed" approach to really break my workflow. I have a lot of temporary uncommitted files, which are not ignored or excluded. Some may eventually be committed but most won't. Being then forced to commit these (but only some due to file size) just gets in the way and impedes things like cross branch debugging A checkout is a working space aft…

auto add is nice for universal undo for changes made outside your editor...

instead of adding changes to a new commit, i split/squash them into the previous one so the current commit remains dirty

Re: Defeating Git Rigour Fatigue with Jujutsu

#144

Post by vaylian »

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

Re: Defeating Git Rigour Fatigue with Jujutsu

#145

Post by JimDabell »

gertburger wrote: post #131

I'd like to give jj another go but I found the "all files must be tracked/committed" approach to really break my workflow. I have a lot of temporary uncommitted files, which are not ignored or excluded. Some may eventually be committed but most won't. Being then forced to commit these (but only some due to file size) just gets in the way and impedes things like cross branch debugging A checkout is a working space aft…

When you are ready to record a change, split your current working changeset and pick the things you want to commit. It’s equivalent to staging then committing with Git.

Re: Defeating Git Rigour Fatigue with Jujutsu

#146

Post by Balinares »

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.

Re: Defeating Git Rigour Fatigue with Jujutsu

#147

Post by Balinares »

nine_k wrote: post #32
jolux wrote: post #10

Earlier quoted context omitted.

I assume you mean named branches (bookmarks in jj)? Because anonymous branches in jj are trivial: you just `jj new ` and you have a new branch. Bookmarks aren’t that bad either IMO, especially with the recent addition of `jj bookmark advance`. Curious if you can say more about the particular difficulties you found keeping them up to date?

Imagine that you use jj, while everyone else who works on the repo along with you uses regular git. Is it easy?

Yeah, trivial. Only difference my teammates see is that my commits are much tidier and scoped in a way that's easy to review and think about.

Re: Defeating Git Rigour Fatigue with Jujutsu

#148

Post by Zizizizz »

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 review changes and review it all at once. It's not about the clean history, it's about making the reviewer's life easier with larger features.

The commits might get squashed anyways so the history on main won't necessarily match what's on the feature branch.

You can commit before you raise a pull request, I don't quite understand that point but I might just be missing something about your workflow that's different to mine.

Re: Defeating Git Rigour Fatigue with Jujutsu

#149

Post by jeltz »

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?

Yes, it us common among people who use git and it makes reviews of complex features much easier.

Re: Defeating Git Rigour Fatigue with Jujutsu

#150

Post by steveklabnik »

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?

See this gist (and the discussion) https://news.ycombinator.com/item?id=41505266
Post reply on HN