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

Jujutsu for busy devs

maddie.wtf

Post reply on HN
Print view View original

531–540 of 552 posts

Re: Jujutsu for busy devs

#531

Post by paradox460 »

stouset wrote: post #447
exographicskip wrote: post #397

Earlier quoted context omitted.

mise is awesome. Put it off far too long after a bad first experience. Now I'll never go back to asdf

Mise really is awesome. We are coming into a new golden era of tooling and I want everyone to experience these things. IMO this is all being driven by Rust. jj, mise, ripgrep, fd, bat, eza, delta… all of the best of breed tools these days seem to be coming out of that ecosystem.

Mise just grew support for GitHub, gitlab, and arbitrary http as sources for tools. The ubi integration previously covered much of this, but had blind spots for things that were "bigger" than just a single binary

Re: Jujutsu for busy devs

#532

Post by sshine »

dmsnell wrote: post #355
sshine wrote: post #324

Earlier quoted context omitted.

> How fast I can deliver value is almost never gated by my VCS Oh, the number of times I do git commit --fixup ...searches `git log` and pastes`... && \ git rebase -i --autosquash ...that same commit^... I waste several half minutes several times per day in periods! Another time-consuming thing is context-switching from a feature branch with staged/unstaged changes. If you're good with worktrees, you can largely avoi…

You can interactively rebase after the fact while preserving merges even. I usually work these days on stacked branches, and instead of using —-fixup I just commit with a dumb message. git rebase -i --rebase-merges --keep-base trunk This lets me reorganize commits, edit commit messages, split work into new branches, etc… When I add --update-refs into the mix it lets me do what I read are the biggest workflow improvem…

That’s great advice, thanks for sharing --update-refs!

But I don’t see how that removes the usefulness of fixup commits, only that you can do them across stacked branches with ease.

But you’re saying I don’t need the particular hash of the parent, I can just rebase all the way back to main/trunk each time. That’s a good point!

I think I’m still saving time by fixup, it was the second hash lookup I wasn’t happy with.

I like to rebase my fixups immediately when possible so I don’t forget.

Re: Jujutsu for busy devs

#533

Post by BeetleB »

frizlab wrote: post #529
BeetleB wrote: post #528

Earlier quoted context omitted.

> Rebasing is an atomic task I may be misinterpreting your position, but I suspect you consider rebasing and fixing conflicts together as the atomic task. In jujutsu, these are two separate tasks. You do a rebase. Even if there are conflicts, the rebase is done . Fixing conflicts is its own task, and can be done at your leisure - no need to couple the two. It's like writing some code that broke a test. You don't say…

> You don't say "Hey, I'd rather not work on anything else until this is fixed." Hey that’s where we differ I guess! I do (most of the time, and if I truly need to switch, my workspace is cloned usually at least twice, using worktrees, so I can indeed switch whatever the current status of everything). This is broadly what I was saying above, most of the “problems” git have are solved with worktrees, that have the und…

Actually, my experience is still at the beginner level - I switched only weeks ago.

If you have 3 branches, you can create a new node that is the merge of all 3. But your question is will it keep up with the changes.

If all 3 branches are local to your machine, and have not been shared, and you edit a prior commit, then all descendants are rebased and thus that merged node will get the changes - no new merges needed.

I think your real question, though, is if one of the branches gets a new child node, can we have the merged node dynamically merge from the new child, rather than from its parent?

I honestly don't know - but I actually do have a need for this! jj has bookmarks, and you can create a merge using bookmarks, but whether the new node will autoupdate if the bookmark moves - something I'd need to experiment with.

Finally, when you have shared/pushed your code, jj will treat shared nodes as immutable, so some fancy jj stuff becomes disallowed.

Re: Jujutsu for busy devs

#534

Post by forrestthewoods »

BeetleB wrote: post #493
forrestthewoods wrote: post #85

Earlier quoted context omitted.

> You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. I’ve tried jj on three occasions and I always get confused by something and just bounce. It hasn’t clicked for me. I’ve only tried it solo hobby projects. For which git is perfectly tolerable. I have many many many complaints about git. But jj doesn’t move the needle for me. Reading this post I am extremely annoyed.…

> I also really really really hate the jj log rendering. The colors are a sea of barf. Bolding the leading character that represent uniqueness is stupid and adds noise. The username being second is dumb, I almost never care about that. And the bright neon green (empty)(no description set) is such bad spew. Kinda nit picky, but blech. Must be a preference thing. Showing me the unique characters is awesome. Git sucks a…

> Showing me the unique characters is awesome. Git sucks after getting used to it.

I regularly jump around commit hashes. However 99.9% of the time a commit hash is printed I am not going to go to it. So it’s pure noise 99.9% of the time. And the absolute most it can save me when it isn’t noise is a few keystrokes. Not a good design imho.

Re: Jujutsu for busy devs

#535

Post by packetlost »

wredcoll wrote: post #453
packetlost wrote: post #364

Earlier quoted context omitted.

Basically see how the LKML works. Individual commits are typically expected to be self-contained to the best extent possible, with patch sets or patch series being used when that's not feasible. Patches are usually sent over email, but there are a lot of ways to do it. It's not an ideal way to operate for most shops, but there's really no reason you can't have a PR/MR/changelist/whatever that is a single branch with…

> Basically see how the LKML works. Individual commits are typically expected to be self-contained to the best extent possible, with patch sets or patch series being used when that's not feasible. Patches are usually sent over email, but there are a lot of ways to do it. What is the advantage to this, other than maybe being easier to send over email? To me, the important part is you have a logical "unit of change" th…

There's quite a few advantages to having a single commit being the unit of change:

- reverts are significantly easier

- bisect will work because the code is expected to code/run at every commit

- rebase becomes easier in the common case

- the transport does not matter, at all. Fully anonymous contributions are possible

- commit messages are easier to write because the changes are smaller and more focused

Several commits could encompass changes necessary to make a particular feature work (ie. patchset) but because each commit is self contained they can be reviewed and tested individually (in order, usually) instead of a one big diff. It's easier on the reviewer, though there's likely a bit more overhead.

Re: Jujutsu for busy devs

#536

Post by paradox460 »

turboponyy wrote: post #197
stouset wrote: post #133

Earlier quoted context omitted.

The staging area is a hack in that it is its own unique concept that doesn't work with any of the rest of git's tooling without needing special, inconsistent flags for commands to target it (git stash, git reset, etc.). I use a staging area with jj! I would surmise most jj users do too. It's just a real, honest-to-god commit in the repo instead of a special snowflake. # do some work … # prepare a new, empty commit if…

Can you edit commits by adding on only parts of your "staging" area? Because that's my workflow. I produce a few focused and semantically coherent commits that I'd like to apply to the codebase, where each keeps the codebase in a working state. I might be working on more than one thing at once, but I know which commit each set of changes should "live in." An append-only log of commits is decidedly not something I wan…

Yes. You can use jj split to cleave changes out into their own commit, and JJ squash to move changes into another commit

Re: Jujutsu for busy devs

#537

Post by sngz »

arunix wrote: post #301
sngz wrote: post #139

Earlier quoted context omitted.

I always go back to using mercurial for personal projects. Better than both

Can you say more about how it's better than both?

easy to understand and use for everyone. you no longer need to spend tons of time teaching junior devs how to use git. By default mercurial also doesn't let you change history. There's no staging area or indexing before the commit. The gui and commands make total sense to the layman.

Git is definitely more powerful but causes more damage than good and wastes more time in most workplaces who are just looking for some simple version control and branching/merging features.

Re: Jujutsu for busy devs

#538

Post by Filligree »

1718627440 wrote: post #310
notmywalrus wrote: post #299

Earlier quoted context omitted.

I would call `jj absorb` a new feature (new if coming from git, I believe the idea was taken from hg). It moves diffs into the closest ancestor that touched those files/lines. Very useful for addressing reviews, then just `jj absorb` and watch them get squashed into the correct location. This gets even better with octopus merges (known in the jj community as "megamerges"): open up 5 branches at the same time, address…

I do use git absorb, but its true, you have to install it. I have never tried git absorb across merges, no clue if that works.

It does not, or at least not very well. Merges can't be rebased without replaying conflict resolution; since Git lacks a first-class concept of conflicts, that becomes a manual process.

Moreover, jj should be able (I haven't explicitly tried this) to autogenerate the conflict resolution in the `jj absorb` case, since it knows what the final post-merge state should be.

Re: Jujutsu for busy devs

#539

Post by Filligree »

npinsker wrote: post #110
resonious wrote: post #108

Earlier quoted context omitted.

I used jj for several months, then eventually went back to git. The biggest killer was performance. jj operations took several seconds for me, whereas git is instantaneous no matter how big the project. Maybe this is fixed now. But also honestly I felt like there was a bit more mental burden to using jj. When I switched back to git, it was like a weight off my shoulders. Maybe that's just due to the decade of constan…

I used to have the same problem (on Windows only, not Mac) but it seems to have been fixed as of a month or two ago.

There's a noticeable delay when doing operations on Nixpkgs (to the tune of a quarter-second), but that's a huge repository.

Everything else is instant.

Re: Jujutsu for busy devs

#540

Post by therealpygon »

stouset wrote: post #154
palata wrote: post #143

Earlier quoted context omitted.

> For anyone who's debating whether or not jj is worth learning I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day. I can totally imagine that some people spend their day manipulating repos with git, and jj is better for them. But that's not my case, and git is already everywhere. To me it sounds like telling me: "You HAVE TO move to bim , the b…

For a lot of people, making small and tightly-focused branches that are easy to review and merge is very important. This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, but you still want to create commits as if this work was all done in tiny and discrete chunks. It's also very helpful if you're the kind of developer who makes lots of unrelated chan…

To be clear, I haven’t used jj so please correct any misundersrandings. I hear you and agree that smaller PRs are definitely easier to understand. On the flip side, it sounds like jj just trades large PRs for lots and lots of smaller, independent PRs that are seemingly unrelated despite all belonging to the same change? I wouldn’t see that as better because, on face, it would sound like far more opportunity for changes to leak out of an actual change-set. Or is the suggestion that the advantage is that each one of those discrete changes carries a comment? Because if developers are lazy, which clearly it is laziness to not use stash for unrelated changes, why wouldn’t I expect every comment to eventually be “{feature}” for everything? So now we need to put more policies in place about how devs should spend more time commenting every one-line code change they make that became an individual PR? And I’m sure jj is going to provide me with a handy feature for then re-grouping all these changes together…back into the original big PR that would have existed in the first place? That seems like a circuitous route to arrive at the same place, but with added risk of unintentional, or worse, missing integration of parts of features that appeared to be independent changes? Ive never found it difficult when I make an unrelated change to just stash that change and add it to its own branch related to a bug ticket at the end of my day. Jj wouldn’t replace 90% of those processes so it sounds like a new way to avoid typing a few commands, by typing more commands more frequently and shifting the workload from a single large relevant change to many, many small changes, all of which were still part of the same set of changes.

None of that sounds like a positive to me, so I’d rather appreciate some evangelism to enlighten me and correct my misjudgments/misunderstandings which I fully admit are likely. :-)

Post reply on HN