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

101–110 of 193 posts

Re: Defeating Git Rigour Fatigue with Jujutsu

#101

Post by dzaima »

kccqzy wrote: post #88
dzaima wrote: post #87

Earlier quoted context omitted.

But you probably haven't spent time writing commit messages before a branch is finished. Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change; replacing a chore with a much bigger chore. Restricted and summarized is good - easier to find/remember, less fluff in a list. And easier to recognize a short identifier from a list of the 2-3 most recent b…

> But you probably haven't spent time writing commit messages before a branch is finished. Wrong. With jj, I use `jj describe` before I start work. It is like writing out a plan for what I want to do. > Or, if you have, you've quite potentially just wasted time writing something that will be rewritten anyway as things change. Rewriting it is not wasted time. It is an opportunity to look at what I have written in the…

> It is like writing out a plan for what I want to do.

I usually don't have a plan for the end; certainly not what any specific commit would be; sure, I could make one (and either make my future self have to do extra work to figure out what commits with lies in their descriptions actually do, or continuously update the commit message marking what actually exists), but as I said that's basically a waste of time. (if you like comparing with past thoughts, sure, but that's definitely not a necessity for a workflow to be reasonable)

"is/isn't an ancestor of the bookmark" is also just a pretty damn good short-hand for denoting a separation between what's been considered the best attempt at the goal, vs things with known problems or just unrelated to the task.

At the core, this if all of course just a question of workflow; if you go into a thing with a plan, meaningful outlook of a non-vague destination, and without expecting continuous switching back&forth between a dozen other things over the time span the branch is alive, caring less about branches or branch names can perhaps work.

> The first line of a commit message is already a summary of the work done.

But you can't (sanely) use it to reference the branch in a revset, can't find it anywhere other than the full log (that's interleaved and mixed with a bunch of other things that you won't ever need to search for), and actual English just gets in the way for finding it, remembering it, and identifying it in a list.

This alone means that, even if I found interest in massively-ahead-of-time-describing commits, having a sane branch reference is still simply just necessary.

Re: Defeating Git Rigour Fatigue with Jujutsu

#102

Post by em-bee »

justinpombrio wrote: post #71
y1n0 wrote: post #65

Earlier quoted context omitted.

I think I said named branches, but that is definitely what I mean. I find it strange that people want to work on anonymous branches, but to each their own. I don't so that has no appeal to me. I often work on something and then switch away to something else. it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing. Other people often need to check out a branch I…

> it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing. Ah, this is what the description (what git would call the commit message) is for. You can set the description even before you've made any changes.

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.

Re: Defeating Git Rigour Fatigue with Jujutsu

#103

Post by oefrha »

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

Yeah it’s smarter than that, but as a daily user of git absorb it still gets things wrong fairly often though—like a couple times a week often for me. Plus the changes it can’t absorb automatically (e.g. a lone doc change it can’t find peers for).

Re: Defeating Git Rigour Fatigue with Jujutsu

#104

Post by em-bee »

cpeterso wrote: post #97
paradox460 wrote: post #80

Earlier quoted context omitted.

They added auto advance bookmarks a while ago. You configure which revset bookmarks you want to advance or not, and then it just keeps them at the "head" of a branch

Having to list all the bookmarks you would list to auto-advance in your jj config.toml is a hassle and easy to forget.

ideally this should be done automatically when you create the bookmark, maybe with a commandline option: jj bookmark create -a/--auto-advance ...

Re: Defeating Git Rigour Fatigue with Jujutsu

#105

Post by jwiz »

RobotCaleb wrote: post #75
y1n0 wrote: post #70

Earlier quoted context omitted.

That's great that it has things you like. I don't do rebasing, except on MRs where I've come to prefer squashing the branch being committed. But I don't rewrite history. It's history. While I can understand people have reasons to do it, the reasons have never resonated with me. I'd rather spend my time getting new work done and not polishing work I've already done.

I'm excited for your delayed comment. I'm sure going to take note that you delayed it and come back later to read it because I'm super interested in what it is that you've delayed. You know, you can just write the comment instead of holding your place in line

The delay is on HN side, when people reply too quickly.

Re: Defeating Git Rigour Fatigue with Jujutsu

#106

Post by stouset »

3eb7988a1663 wrote: post #47
stouset wrote: post #46

This seems like a lot more effort than the (to me) more natural jj workflow of maintaining the idealized series of commits plus a working commit on top. As you make tweaks and fixes you just squash the relevant parts into the already-clean history. Basically, if you don’t get into that sort of situation with commits containing parts they shouldn’t in the first place, you don’t need to do any extra work to clean them…

That is a lot of discipline up front. I am sure there are problems which are nicely bucketed, but I usually have to go with the flow and make changes as I see them. I want to keep working with the code, not babysitting version control as I focus on getting the initial version to work.

It’s really not.

I start a new branch and begin work. When I’m ready to start organizing that work into a consistent narrative (or when bits are “finished”), I split it out into independent commits. As I keep making fixes and tweaks, I continue squashing bits from my working commit into the parent commits they belong on.

I don’t bother making any independent commits until pieces of what I’m working on are becoming fully-formed. Until then, my working commit just has everything.

Re: Defeating Git Rigour Fatigue with Jujutsu

#107

Post by skydhash »

ninkendo wrote: post #60
jadar wrote: post #58

I tend to just commit whenever I see fit, then at the end I do a `git reset —soft` and write the history that makes sense before pushing.

I always tell people I use a “git reset” based workflow. I rarely “checkout” branches, I just stay on main, reset hard when switching topics, reset soft when squashing, and I only name my branches on the remote end via “git push origin HEAD:some-branch”. `git branch` is basically my bookmark tool. I commit for a while, then when I want to remember where I am for later, `git branch wip/topic-a-finally-compiles` or wha…

I follow something similar, especially with the PR process and squash-merge on remote. I do the first ticket push using explicit ref, then just continue on the next one, while I wait for the review process. When the first PR is merged, I rebase on top of the remote branch and do the same for the second PR.

I do switch branch for long experiments and touch up on existing PR.

It would be great if a PR was about distributing patches and not having those automatically generated from a branch.

Re: Defeating Git Rigour Fatigue with Jujutsu

#108

Post by sakompella »

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 had this exact friction trying to use jj this weekend. can't fathom for the life of me why i have to run another command that updates the branch to the next commit.

Re: Defeating Git Rigour Fatigue with Jujutsu

#109

Post by RobotCaleb »

jwiz wrote: post #105
RobotCaleb wrote: post #75

Earlier quoted context omitted.

I'm excited for your delayed comment. I'm sure going to take note that you delayed it and come back later to read it because I'm super interested in what it is that you've delayed. You know, you can just write the comment instead of holding your place in line

The delay is on HN side, when people reply too quickly.

Oooh, my apologies, then! I misunderstood

Re: Defeating Git Rigour Fatigue with Jujutsu

#110

Post by stouset »

matheusmoreira wrote: post #100
steveklabnik wrote: post #79

Earlier quoted context omitted.

jj allows your commits to stay in a conflicted state until you choose to resolve them. I wrote about this a month ago: https://news.ycombinator.com/item?id=47767292

I see. It doesn't deal with the conflict, it just proceeds regardless. I'm curious about how it works internally. Does it do something like commit the conflict and soft reset later?

The conflict markers are a first-class citizen in the repo. jj tells you when a commit has a conflict, and you can go edit it at your leisure. It also does prevent you from doing some things with branches in a conflicted state, like pushing them.

You might not think this is that big a deal, but this also means you don’t have to resolve the entire thing in one go. Plenty of times with complicated rebases in git, I’ve not been 100% certain about the path towards resolving it. But jumping around to view various commits when you’re in the rebase-conflict state is painful. In jj you can just switch to an earlier commit, tweak it there, jump to a later commit, see how it looks, etc. It removes 98% of the pain.

It also dovetails nicely with other aspects of jj. Since rebases happen automatically and constantly, they are usually tiny. If there’s a conflict, it’s caught right when you do the thing and not four hours later when that part is no longer fresh in mind. And the op log lets you restore and undo actions atomically, which makes undoing a fuck-up a no-op.

Post reply on HN