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

491–500 of 552 posts

Re: Jujutsu for busy devs

#491

Post by BeetleB »

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;

I hit this - I develop in Windows.

I still prefer jj and won't go back to pure git :-)

Re: Jujutsu for busy devs

#492

Post by BeetleB »

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 you don't.

Re: Jujutsu for busy devs

#493

Post by BeetleB »

forrestthewoods wrote: post #85
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. 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 after getting used to it.

Re: Jujutsu for busy devs

#494

Post by BeetleB »

1718627440 wrote: post #185
sunshowers wrote: post #52

Earlier quoted context omitted.

I do mean suspending the rebase and going to do something else, yes. It's a weird thing to do in git , because the conditions that git creates makes it weird. It is completely natural with jj, because jj doesn't have any modal states at all. (This is one of the key reasons jj is both simpler and more powerful than git — no modal states.)

You can absolutely do that in git: git checkout master git rebase [whatever] [rebasing stuff] git tag rebasing git checkout --detach master [do random other stuff] git tag todo git checkout rebasing [continue rebasing] When you are not trying to modify the same branch you're rebasing, you can omit --detach and also git tag todo. (To clarify, it has never occurred to me that I even want to do that, so I didn't knew ho…

I know you're trying to point out how easy it is in git, and some months ago I would have agreed. But after using jj (for only a few weeks!), your commands seem needlessly complex.

In jj, you run the rebase command. If you get conflicts, and want to switch to something else before you fix all of them, you simply do "jj edit" or "jj new" and work on something else. Then you do "jj edit" to go back to the conflicted revision and get back to fixing conflicts.

The key point is: You don't need to learn any new concepts.

In the git example above, I need to know tagging. I need to know checkout vs "checkout --detach", etc.

I'm not saying your git commands are crazy complex. They're merely more complex than one needs to solve this particular problem.

Re: Jujutsu for busy devs

#495

Post by BeetleB »

frizlab wrote: post #165
sunshowers wrote: post #78

Earlier quoted context omitted.

I feel like I just outlined a situation where something that's weird in git is completely natural in jj. Maybe I miscommunicated?

I think you communicated well, probably I did not. > suspending the rebase and going to do something else This is what I find to be weird, personally. When doing a rebase, there’s no way I want to do something else in the middle of it, and having a modal state feels totally natural to me. At first approach (I read a (very good) intro[1]; I did not try), it seems there’s a lot of new things to learn (for instance the…

> This is what I find to be weird, personally. When doing a rebase, there’s no way I want to do something else in the middle of it, and having a modal state feels totally natural to me.

When I was pure git, I agreed.

Let me reframe your comment:

"When working on a feature, there's no way I want to work on some other feature in the middle of it"

(which is how many people felt before ever using version control and branches).

With jj, I do it all the time. The tool made the difference. A rebase is not something "special". Switching from a rebase to working on another feature in the middle is exactly just like switching to another branch in the middle of working on the current branch. It's the same (or very similar) set of commands.

When you realize this, then yeah - leaving in the middle of a rebase is pretty normal, and you wonder why people don't do it.

Re: Jujutsu for busy devs

#496

Post by BeetleB »

frizlab wrote: post #469
stouset wrote: post #435

Earlier quoted context omitted.

> When doing a rebase, there’s no way I want to do something else in the middle of it, and having a modal state feels totally natural to me. This is a consequence of rebases being a special, modal state that requires dedicated focus to work through to resolution. Rebase conflicts are (to a jj user) just another fix you might want to make to a revision. Or it might be better done by making a tweak to an earlier revisi…

> This is a consequence of rebases being a special, modal state that requires dedicated focus to work through to resolution. 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… Relaxing this comment which is a bit aggressive: at least it’s how I work. YMMV.

> 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."

Re: Jujutsu for busy devs

#497

Post by juped »

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…

This is actually the main reason it exists in the first place, so given that fact, you should probably not use it?

Re: Jujutsu for busy devs

#498

Post by spott »

dilap wrote: post #342
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…

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?

Re: Jujutsu for busy devs

#499

Post by oxidant »

arccy wrote: post #234
oxidant wrote: post #71

Earlier quoted context omitted.

Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.

you've obviously never encountered code which only works when println is added.

Schroedingers branching

Re: Jujutsu for busy devs

#500

Post by keyserj »

sethammons wrote: post #168
stouset wrote: post #154

Earlier quoted context omitted.

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…

Nice commits can really tell a development story that makes reviews easier. That said, I want all teams to squash merge their feature into master after tests pass. One commit at the end, and one commit to remove in case of an issue affecting customers related to the release. A very, very large problem at five out of six companies I have worked at is casual code improvement and refactoring. Devs would say, "we will ad…

> I want all teams to squash merge their feature into master after tests pass. One commit at the end, and one commit to remove in case of an issue affecting customers related to the release.

Hmm what's the issue with the GitHub default of merging PRs, where there's a merge commit which individually pulls in the PR's commits? You can revert the merge PR as a whole, or the PR commits individually. E.g. with this[1] merge commit, you can `git revert 0a98f570 -m 1` (the merge commit) or `git revert b30950fc` (an individual commit from the PR).

[1] https://github.com/amelioro/ameliorate/commit/0a98f570f63ffd...

Post reply on HN