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

191–200 of 552 posts

Re: Jujutsu for busy devs

#191

Post by nchmy »

sunshowers wrote: post #20
arp242 wrote: post #15

Earlier quoted context omitted.

I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

I think jj just uses the 4 bit (16 color) terminal palette, so if a color is unreadable, you can update your terminal theme accordingly.

Jjui is by far the best TUI for jj and just released a Themes feature yesterday. It's well worth checking out.

https://github.com/idursun/jjui

Re: Jujutsu for busy devs

#192

Post by dzaima »

MrJohz wrote: post #182
dzaima wrote: post #135

Earlier quoted context omitted.

> What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready. I was extremely hostile to this aspect of jj too, but I've settled on a workflow where @ (i.e. the change/commit referring to the working copy) is always the same, named ".WIP: …", and as such is clearly never supposed to break out of the local system, and can never accidentally get pushed…

If you leave the WIP head change blank, i.e. don't give it a description at all, then JJ will block you from pushing it unless you pass a specific flag, which is useful for sanity checking this sort of stuff. You might be able to configure JJ to also block commits with certain descriptions as well, which might be useful in your case.

I specifically have the WIP head description include the name of bookmark that it's attached to, if any (emulating git's non-detached head), so can't leave it empty (and generally wouldn't want to, for easy way to identify it, esp. with multiple workspaces).

Some push blocker for certain commit name patterns would make sense to look into.

Re: Jujutsu for busy devs

#193

Post by rfoo »

sethammons wrote: post #176
bjackman wrote: post #45

Earlier quoted context omitted.

Counter point: I adopted it internally at Google (there's a backend for Piper, Google's monorepo Perforce thingy). I don't do my day-to-day work in the monorepo but I still jump in there once or twice a week. I adopted JJ because the existing frontend (Mercurial-based) is slow while JJ is fast. It's nice, I really like it! I'll probably switch to it as my main VCS eventually. But it doesn't feel that important to me.…

Curious, I was under the impression that Google was all a monorepo, but your phrasing suggests that there are others. As my company is pushing for a monorepo, I'd love to know what causes someone at big G to not be in the monorepo. Thanks for any insights you can help me with!

Mainly open source stuff. Chromium, Android, etc.

Re: Jujutsu for busy devs

#194

Post by nchmy »

benoitg wrote: post #87
_bent wrote: post #12

I've been using jj for two weeks now and it's kinda exciting, because for the first time I'm comfortable with using version control just via the command line. With Git I always had to use a GUI (preferably Git Graph in VSCode) and launch all operations by right clicking items, but jj was simple and consistent enough that I could just start using it after reading Steve Klabniks tutorial. The thing I'm running into rig…

I had the same copy paste problem, now I use jjui ( https://github.com/idursun/jjui ). The daily operations become even smoother, it looks like I’m flying over the log.

This is The Way. jjui makes jj's power and simplicity even more powerful, simple and beautiful

Re: Jujutsu for busy devs

#195

Post by nchmy »

fxmc wrote: post #175
fn-mote wrote: post #157

Any tips for a magit fan who wants a positive second experience with jj? I’m used to sorting through the changes I have made and making separate commits for each unrelated one (eg bug fix for several files, some WIP work, other parts actually done and ready to be “shipped”/reviewed)? Do I need a better workflow? Should I just be using the command line?

I came from magit and completely switched to jj for the much easier handling of sets of changes that you describe. jjui ( https://github.com/idursun/jjui ) made this a lot faster and more enjoyable.

This x1000. Jjui is beautiful

Re: Jujutsu for busy devs

#196

Post by weinzierl »

nchmy wrote: post #179
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…

Yeah, I regularly have MANY "staging commits" at the same time in jj, in which I just throw ideas in that I don't want to pollute or yet know how to integrate with the other ideas. I use squash, split, interactive split, rebase etc to move lines and changes around etc... When I eventually figure it all out, I can tidy it all up into completely coherent, discrete, sequential commits that make it look like I knew exact…

Hmm, never saw it that way. Maybe I just need a different perspective on commits. Thanks for your comment, that was insightful.

Re: Jujutsu for busy devs

#197

Post by turboponyy »

stouset wrote: post #133
weinzierl wrote: post #124

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. " Reporting in. Doesn't mean I will not end up with jj eventually, but so far I always went back to git after a while. For me it is the staging area and the workflow it allows. Most people hate it and love jj because it does away with it. That is just not me. I don't see the staging area as a hack that was necessary…

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 want. Is jj amenable to this?

Re: Jujutsu for busy devs

#198

Post by nchmy »

do_not_redeem wrote: post #55
accelbred wrote: post #39

Is there a magit equivalent? I heavily use magit's interactive features and extensions to the git UI (like spinoff, absorb, or the auto-backup thing)

jjui is the best VCS TUI I've ever used. It's even smoother than magit, but I think most of that is because of jj itself. Spinoff and absorb are both native jj features (jj rebase and jj absorb, respectively) https://github.com/idursun/jjui

Completely agreed. I've been evangelizing jjui even more than I do jj!

And, you're right, it's powers largely come from the underlying jj - it mostly just runs jj commands behind the scenes, parses the output, and displays it. But it's all so beautiful, seamless etc..

I can't wait to really dig into the big additions released yesterday in v0.9.0 - themes, vim-like leader key shortcuts, other shortcuts etc...

Re: Jujutsu for busy devs

#199

Post by maddiemort »

doritosfan84 wrote: post #3

I’ve been trying unsuccessfully to convert my team to jujutsu. I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. Something like the elevator pitch here but expanded on without the depth of Steve’s tutorial. Maybe what I need to do is do a demo so people can see and ask questions.

I think you'll probably like the next part I'm going to add to this post, then! I'm sure it'll get posted separately, but it'll also appear at the bottom of the page linked here when it's up (hopefully soon, as in the next few days).

Re: Jujutsu for busy devs

#200

Post by aniforprez »

nottorp wrote: post #153
flockonus wrote: post #86

I legit ask myself how many folks avoid Github Desktop for some dogmatic reasoning equivalent to "having an UI makes it worse", when it does the core of common flows extremely easily and clear. To be clear where it ties to this post: it makes git far more convenient with nearly 0 learning curve.

Judging by the name, Github Desktop works only with github... ?

I'm not sure if there's advanced commands that GitHub Desktop does more with but for the most part it's just a porcelain frontend that works great for doing simple operations but can't do things like interactive rebases, reflogs, blames and so on. It's a pretty simple frontend to get started if you're just learning git. There's not much it does that's GitHub specific. If you're logged in, it will easily checkout your upstream repos.
Post reply on HN