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

521–530 of 552 posts

Re: Jujutsu for busy devs

#521

Post by 1718627440 »

0x457 wrote: post #481
1718627440 wrote: post #452

Earlier quoted context omitted.

> May I use Was that 'may I ask'? Not that often, but not seldom. Its useful if you have a bug, that isn't obvious where it comes from, but easily testable. Then you just write a test and let git figure out where it comes from. The test doesn't need to be automatable. I also used it for firmware that needs to be flashed and the bug effected in an LED blinking incorrectly. I still saved a lot of time.

> Was that 'may I ask'? Yes, can't type sometimes. I see. Maybe it's just what kinda of code and/or how I write it, usually pretty clear which abstraction isn't doing its thing. From there, it's either clear what is the bug, or git blame will reveal what changed. This has a much higher chance of succeeding if you maintain strict boundaries and isolation which isn't always possible.

In addition to bugs this is also useful to pinpoint behaviour change.

Re: Jujutsu for busy devs

#522

Post by palata »

palata wrote: post #143
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…

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

Actually I find this tutorial to make a really good point in introducing it Jujutsu [1] without implying that "if you don't know it you don't know the Truth/haven't seen the light/are a peasant".

The author starts by saying that they actually have no issue with the git CLI, which is exactly my case.

I started trying jujutsu and until now, I can describe the feeling as an ergonomic keyboard: I am fine with any keyboard, really, it's not that some keyboards are "hard to use". Nobody would (should?) say "with a cheap keyboard, you can't type fast enough to be efficient, but with this ergonomic keyboard, you will be faster". But one may find that an ergonomic keyboard is more comfortable for them, or that it sounds a bit better or feel a bit better.

There is no real need to change keyboard if you like yours. It doesn't mean that it's impossible to find another keyboard that would be more pleasant to use.

JJ may be that (for me, but again I'm just starting): it seems equivalent to git CLI (as in, it's not a heavy GUI or a VScode plugin: it's really a CLI) and it feels like it may be more ergonomic.

And at the very least, it's fun to try.

[1]: https://steveklabnik.github.io/jujutsu-tutorial/

Re: Jujutsu for busy devs

#523

Post by mpyne »

BeetleB wrote: post #486
mpyne wrote: post #392

Earlier quoted context omitted.

I'm sure it's great but I don't have the problems with git that others apparently do, so as to make it worth switching to a whole new mental mode of source code management. At least uv solved real problems I was having with Python package management, but for my own personal usage git is 99% aligned with what I need.

Just FYI: The person you're responding to wrote a very popular tutorial on jj. He's been using git since the early days, and as he puts it: > Now I am not one of those "the git CLI is too complex and git is too hard to learn" people, but I do acknowledge that puts me in the minority. But let's reframe that: if we can make something more powerful and easier? Sign me up!

> Just FYI: The person you're responding to wrote a very popular tutorial on jj.

That's nice.

I know of him better from his Rust work, but he explained himself well enough in his own comment that he probably doesn't need your assistance to reiterate a point he made very effectively on his own.

Also, he's not the only one who's used git since the early days.

Re: Jujutsu for busy devs

#525

Post by dilap »

spott wrote: post #498
dilap wrote: post #342

Earlier quoted context omitted.

There is a 3rd group (probably mostly gamedevs) who think it seems like a great idea and really want to try it, but are blocked waiting for git-lfs support. Every time jujutsu pops back up on HN I check to see if they've added it yet. Not yet! But they are slowly getting there: https://github.com/jj-vcs/jj/issues/80

Do you know what this means in practice? Is it that I have to fall back to git for its changes? Or that I just shouldn’t use jj if I’m in a repo with lfs files?

I'm not sure, if you scroll through the bug report there seem to be some people maybe kind of making it work, but I couldn't figure out exactly what they were doing, so decided I'll just keep waiting for the real implementation.

Re: Jujutsu for busy devs

#527

Post by modulared »

BeetleB wrote: post #492
WhyNotHugo wrote: post #181

The main things that drives me crazy about jj is that all changes are always staged implicitly. This is what SVN did back in the day, and git was a huge improvement by staging changes explicitly. I almost always have more changes in my repository that those which I want to include in the next commit. With git, I just add the changes I want. With jj (and svn), there’s not obvious way around it—you have to manually cop…

I'm torn on this - I don't know if there's a simple solution. Having to stage things every time was always a real pain for me (coming from Mercurial). Having it autocommit is what I need well over 90% of the time. But then there are always those pesky files that for various dumb reasons I'm not allowed to put in .gitignore. I could disable autoadding files, but life will be worse that way. Damned if you do, damned if…

> I could disable autoadding files, but life will be worse that way.

``` [snapshot] auto-track = 'none()' ```

This is what I do, and I don't think it is worse. I prefer not having all my ignored files auto-tracked when I accidentally go back to a commit without them in the .gitignore

Some other solutions (which aren't simple at all): - Remove specific files from auto-track - Have a private commit with changes to the .gitignore and work on top of a merge commit - Like last one, have a private commit with the files you don't want to push (+ merge)

I have it setup where any commit with a description that starts with "IGNORE:" is private.

snippet from my config: ``` [git] private-commits = ''' description(regex:"(?x) # (?x) enables the x flag (verbose mode) allowing comments and ignores whitespace # see: https://docs.rs/regex/latest/regex/#grouping-and-flags

  # Ignores commits starting with:
  # (case-insensitive) PRIV: or PRIVATE:, or IGNORE:
  ^(?i:PRIV(ATE)?):
  | ^IGNORE:
 ")
''' ```

Re: Jujutsu for busy devs

#528

Post by BeetleB »

frizlab wrote: post #520
BeetleB wrote: post #496

Earlier quoted context omitted.

> Believe it or not: no. Humans are notoriously bad at multitasking, so it makes sense to actually finish a task before moving to something else and forgetting what we were doing… Again, see my other comment. It's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done."

> it's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done” Neither. Rebasing is an atomic task, kinda like a commit.

> 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 "Hey, I'd rather not work on anything else until this is fixed." If you want, you either commit it as is (or stash if you prefer), work on something else, and come back to it later to fix the broken test.

Re: Jujutsu for busy devs

#529

Post by frizlab »

BeetleB wrote: post #528
frizlab wrote: post #520

Earlier quoted context omitted.

> it's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done” Neither. Rebasing is an atomic task, kinda like a commit.

> 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 undeniable advantage (IMHO) to actually separate tasks, instead of being in a state where (waving hands) everything is here in this big bowl of stuff (and I’m not saying that dismissively; once again everybody works differently; it’s just not my thing).

I do have understood the “conflicts do not need to be resolved straight away,” though I do not really get it (if there are conflicts the code does not compile anymore, so what is even the point? ok you can switch branch, but still it’s a task that I would know I have to do anyway and I could not switch to something else; my brain does not work that way).

All of that being said, since you seem to know a lot about jj, I’ll take the liberty to ask a question I do have about it, because there is indeed a workflow that I find painful with git that, IIUC, is actually solved by jj.

Let’s say I (or the team) am (is) working on two or three different things on two or three different branches. The full feature is the merge of these branches. Is jj able to maintain a branch which is the merge of all the other branches mostly (or fully) automatically?

Re: Jujutsu for busy devs

#530

Post by paradox460 »

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 tried it a year or two ago and went back to git. I didn't dislike JJ, it just didn't cover all the things I needed to do my usual workflow at the time, and being the only dev on my team using it was a bit tricky

I've been meaning to give it another shot, and probably will after this article

Post reply on HN