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

131–140 of 552 posts

Re: Jujutsu for busy devs

#131

Post by anticodon »

0x457 wrote: post #44
stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.

I used bisect once in my life but it was extremely helpful. Without it I'd spend weeks trying to find regression. With bisect I found and fixed it in under 1 hour.

It's a command that is needed rarely but there's no replacement for it in some situations.

Re: Jujutsu for busy devs

#132

Post by falconertc »

ykonstant wrote: post #123
0x457 wrote: post #44

Earlier quoted context omitted.

Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.

Bisect is a wonderful feature. Git is full of tedium and frustration, bisect is not part of that.

Bisect is a very cool feature that I used once over 5 years ago. The collection of git tools that I use often is very small. I've found that the more experienced I got with git, the less I found myself in scenarios where I needed git's more complex tools.

Re: Jujutsu for busy devs

#133

Post by stouset »

weinzierl wrote: post #124
stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

"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 you don't already have one
    jj new --no-edit --insert-before @

    # move changes into it; repeat ad nauseam
    jj squash --interactive
Since it's just a commit, all your tools work with it out of the box. And you don't need to stash changes when you jump around between branches.

Re: Jujutsu for busy devs

#134

Post by arp242 »

sunshowers wrote: post #127
arp242 wrote: post #81

Earlier quoted context omitted.

I don't control these applications.

If I understand correctly, you're in the situation where you've chosen your 4-bit colors so that they render properly on an application which (incorrectly) uses an 8-bit background color but a 4-bit foreground color, and also that the colors don't render well on the default background that's part of the same 4-bit palette. I think you'd be a great candidate for jj's ability to customize colors.

I don't choose anything; I just use the xterm defaults. Some colours inherently conflict. Blue on white is fine. Yellow on black is fine. Yellow on white is not. White on white is even worse. There are many combinations that don't really work brilliantly. Some applications set background colours, some don't. pamix, ngrok, and npm are examples of applications that hard-code background colours. Configuring the terminal to use text colours that work well with both the default white and hard-coded black (for some applications) is hard.

That I need to spend a bunch of time setting all of this up (among other things) is exactly how this thread started.

Re: Jujutsu for busy devs

#135

Post by dzaima »

ants_everywhere wrote: post #65
Filligree wrote: post #54

Earlier quoted context omitted.

> It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Its Piper backend honestly works better than the Git backend. Which isn't a knock on the Git backend, but the impedance mismatch is worse there. > Some of the design decisions are also not great.…

Thanks, can you link me to their perforce backend code? I don't see the string "perforce" or "p4" anywhere in the code and it's not coming up on search. > You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that…

> 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 down the log. (..my jj workflow is just blatantly copying my git workflow (with the same-name shell aliases/helpers even), but even with said git emulation I'd say it's nicer than git itself)

Still may be weird/undesired to have the local repo preserve the changes (especially annoying if it happens to find an unignored build artifact, though there is a size limit for automatic tracking by default), but it's also rather neat that you can dig out your old deleted printf debugging or whatnot later on if you wanted to.

Re: Jujutsu for busy devs

#136

Post by xelxebar »

stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

It's certainly a solid improvement in the space of VCS UI, but beware that jj has some current limitations which might prohibit switching, especially for the git power users.

Lack of gitattributes support precludes git-crypt and git-lfs usage or anything that needs filters; line ending settings will get ignored, making Windows interop a little less smooth; etc.

Also note that auxillary tooling, such as git-annex and git-bug, becomes second class, i.e. no oplog integration and they might mess up your log with internal-use commits and heads.

Re: Jujutsu for busy devs

#137

Post by baq »

steveklabnik wrote: post #83
0cf8612b2e1e wrote: post #80

Earlier quoted context omitted.

The logic is once you are ready to commit you delete all of the debugging stuff. Otherwise you are committing an illusionary state of the repo that only existed by manipulating the stage. I am a black kettle here as I frequently commit individual lines amongst a sea of changes, but I do appreciate the theoretical stance of jj.

Just to be clear, jj makes it really easy to carry this sort of thing as a separate patch, so while it may be "committed," that doesn't mean it has to go into what you send upstream. (though for debug printfs in particular, the Right Thing is proper logging with log levels, but I myself love printf debugging and so sometimes don't do that either. Which is why carrying local patches is nice.)

There is no Right Thing here. Practicality beats purity. The product (a snapshot of the source tree) should do what it needs to do, but getting there is not the product. It can be if you want it to be, but there is no upside to that.

Re: Jujutsu for busy devs

#138

Post by steveklabnik »

xelxebar wrote: post #136
stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

It's certainly a solid improvement in the space of VCS UI, but beware that jj has some current limitations which might prohibit switching, especially for the git power users. Lack of gitattributes support precludes git-crypt and git-lfs usage or anything that needs filters; line ending settings will get ignored, making Windows interop a little less smooth; etc. Also note that auxillary tooling, such as git-annex and…

> line ending settings will get ignored, making Windows interop a little less smooth; etc.

This one got fixed just a few days ago! https://github.com/jj-vcs/jj/pull/6728

Re: Jujutsu for busy devs

#139

Post by sngz »

stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

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

Re: Jujutsu for busy devs

#140

Post by stouset »

forrestthewoods wrote: post #98
viraptor wrote: post #96

Earlier quoted context omitted.

> I also really really really hate the jj log rendering You can fully change/customise it. Sounds like you just don't like the default.

Some people love to tinker and fine tune their tools to behave exactly like they want. I am not one of those people. I hate it. It does not spark my joy. Most people use the default for most of their tools. It’s why Google pays Apple over $20 billion per year to be the default search engine. Because defaults matter.

FWIW, I am also one of those people who does not want to fine tune their tools. I want my tools to work well out of the box.

> I’ve only tried it solo hobby projects.

If I can surmise a bit, this is probably why it's never felt "worth it". I'm guessing that for a hobby project you don't really care that much about crafting small, easily-digestible PRs or keeping a clean history. `git commit -a` every now and then is good enough, and that's entirely reasonable.

For team projects, jj becomes a much bigger deal. I find it invaluable for splitting up a day's worth of work into small, parallel, easily-reviewable changes. While working on one feature I might run across a dozen other things that should be fixed, improved, or otherwise changed. Bundling them into one giant PR is bad practice and causes reviews to take much longer.

Carving those up into single-purpose PRs that can be reviewed in seconds and tested independently is super helpful on a project with multiple teammates. But that's not something that really matters or that most people care to take the time do to in personal projects. Hell, it's something a lot of people punt on a lot in git due to the extra burden of doing so.

Post reply on HN