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

211–220 of 552 posts

Re: Jujutsu for busy devs

#211

Post by 1718627440 »

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…

You can use commits instead of the stash the same way in git. Isn't this just a way of using, why do you need jj for that?

You now you can give stashs a commit message?

Re: Jujutsu for busy devs

#213

Post by 1718627440 »

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.

Yes not using bisect, seams like you do all the work to record information, but then never use that information to save work?

Re: Jujutsu for busy devs

#214

Post by 1718627440 »

globular-toast wrote: post #151
tcoff91 wrote: post #122

Earlier quoted context omitted.

It’s really nice to use the —-first-parent flag with bisect.

Yeah this is good if you, for some reason, rebase then merge without fast forwarding. I never understood doing this. If I'm going to be ignoring those commits when bisecting then they are useless commits just using up disk space IMO. Does it work well with a classic merge workflow? I haven't worked that way (without rebasing) for a long time.

For me a merge is about grouping commits, when you have just a list of commits, the list can be very long.

That's also useful for bisecting, as you can first find the feature that is buggy and then find the commit that introduced it.

Re: Jujutsu for busy devs

#215

Post by IshKebab »

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…

It's totally possible to have no issues with Git, e.g. if you are only using it for small or slow moving repos.

There definitely are lots of big issues with Git though. I dunno how many jj solves but it doesn't seem unreasonable to suggest people move to a better system.

Re: Jujutsu for busy devs

#216

Post by gabrielgio »

palata wrote: post #149
Filligree wrote: post #57

Earlier quoted context omitted.

> 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. What I find isn't that common git operations are easier in jujutsu. They're not; sometimes they're slightly harder, due to the impedance mismatch with the git backend. Rather, what git makes easier are operations that are next to impossible — or at least highly inconveni…

I do understand that point, but to me it sounds like "you should use jj because it's a lot better at solving problems you don't have". If there are really common use-cases where git is annoying and jj is great, it shouldn't be that hard to explain, should it? If you can say "remember how in the last few days you struggled with this? Jujutsu solves it", then I'm happy to try. If your argument starts with "imagine you…

> "you should use jj because it's a lot better at solving problems you don't have"

It is more like "you should use jj because then you won't have a lot of problem with git that you'd need git to solve"

> it shouldn't be that hard to explain, should it?

It is not. There are plenty of example on this page. For me the biggest one is stacked PR, jj makes it trivial since it tracks the change sets and not commit ids (which are immutable). So you can work on any level of the stacked PR independently, once you're done run "jj git push -r '(trunk()..@ | @::)'" and it will update all the remote branches accordingly. Another feature that works great with stacked PR is that you don't need to solve conflicts right away. You will see a marker in the "jj log" and you can solve it later down the road.

Also another great feature is the operation log, you can just rewind your actions. F'd up a conflict resolution? Just go "jj op undo". That goes for everything, including file changes and rebases. Want to go back the state it was 15 min ago because you didn't like what you did? Merge to the wrong place? "jj op undo"

Adding to that there are hundreds paper cuts that jj fixes, like:

* Simpler mental model for local change, no git stash/add necessary.

* Simpler commit process, you can just work and use "jj describe" whenever where git forces you to write message before creating commit (again because commits are immutable).

* Starting a work is much easier, I can just go "jj new" away without caring about detached head. Nowdays I just use branches (jj bookmarks) for git compatibility reasons.

* Revsets are amazing, much more powerful and expressive than git logs, and since the UX is more consistent you can always work with set of rules that expects a revset with "-r".

Ofc, you can do all of that with git, but it just works better, easier and more consistent with jj.

Re: Jujutsu for busy devs

#217

Post by IshKebab »

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

Arguably a good thing - git's autocrlf setting causes way more issues than it solves. I highly recommend setting it to "input" (basically bans CRLF).

Re: Jujutsu for busy devs

#218

Post by jon-wood »

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'm honestly baffled by this. You're a proponent of dealing with chores as you encounter them during development rather than putting them off til later (great! I love this!), but also when that PR lands you want it all squashed down into a single commit, which presumably will have a message like "Implemented Important Feature, also did a bunch of unrelated work".

That sort of workflow is ideal for making sure you've got a set of isolated commits each looking at a single subject so that when someone is reading through the history later they can quickly see where something was introduced or why, and jj is perfect for doing that because it makes crafting those commits so much easier.

Re: Jujutsu for busy devs

#219

Post by emresahin »

I tried jj a few days but I noticed my lazygit based workflow and scripts already make me productive enough not to deal with another mental model.

jj looks cool in general, I'd start with it if I were just going into this _version control_ thing but for most of us older folks, that doesn't provide enough motivation to change.

Re: Jujutsu for busy devs

#220

Post by viraptor »

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.

But you can't make a default that everyone will like. The best overall interface will have someone hating it. If you want to always use defaults, you're basically guaranteeing that you'll hate some genuinely great software one day.
Post reply on HN