Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Steve's Jujutsu Tutorial

steveklabnik.github.io

Post reply on HN
Print view View original

51–60 of 120 posts

Re: Steve's Jujutsu Tutorial

#51

Post by swiftcoder »

arccy wrote: post #42
swiftcoder wrote: post #39

> I also heard friends rave about "stacked diffs" but struggled to understand what exactly was going on there. Nothing I read or conversations I had have clicked. I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.

because it's a name that describes the technical implementation, not the end user experience

Maybe the problem here is that there aren't any open tools implementing the user experience, because I'd say it's exactly the opposite - that it is implemented using rebase under the hood is entirely secondary to the user experience of "stacking" changes on top of one another.

Re: Steve's Jujutsu Tutorial

#52

Post by sheremetyev »

jFriedensreich wrote: post #46

I am torn between sapling and jj. Both make good progress in git/github integration which seems to have been the major road block in adoption before. One other major roadblock seems to be the limits of review tools supporting stacks: github PRs are too limited, gerrits ux is horrible, graphite does not work and is not open enough, saplings review tool is just a very slow performing POC (though with a really good UI c…

for me important argument in favour of JJ over Sapling was "first-class conflicts" - JJ stores conflicts in the history and allows you to resolve them later, while Sapling forces you to resolve conflicts at the point when they happen

https://martinvonz.github.io/jj/latest/sapling-comparison/

Re: Steve's Jujutsu Tutorial

#53

Post by sheremetyev »

abhinavk wrote: post #50
conaclos wrote: post #48

Earlier quoted context omitted.

> The auto committing behavior is a bit weird at first I am a bit skeptical about this, because this requires a jj daemon?

No from what I see. It does that whenever you run any jj command. I haven't checked the source.

by default snapshotting happens on each jj command

additionally you can enable automatic snapshots when files in the working copy are updated: https://martinvonz.github.io/jj/latest/config/#watchman

Re: Steve's Jujutsu Tutorial

#54

Post by kettleballroll »

chronial wrote: post #33
kettleballroll wrote: post #23

Earlier quoted context omitted.

Same. I miss the old times when people tried naming their projects sensibly. I mean, we're constantly telling ourselves how variable and function names should speak for themselves, but then we name our projects using random, completely non-descript names. It's a annoying.

Which old times are you referring to / what are "sensible" names? I thought about it and I don't know what a better name would be. Off the top of my Head, I know Perforce, BitWarden, Subversion, fossil and git. And then the abbreviations CVS, RCS and SVN. Do any of these qualify as a descriptive name?

I don't just mean version control systems, but since you mentioned them: CVS (concurrent version system), rcs (revision control system) and subversion all seem fairly descriptive to me?

Re: Steve's Jujutsu Tutorial

#55

Post by steveklabnik »

jFriedensreich wrote: post #46

I am torn between sapling and jj. Both make good progress in git/github integration which seems to have been the major road block in adoption before. One other major roadblock seems to be the limits of review tools supporting stacks: github PRs are too limited, gerrits ux is horrible, graphite does not work and is not open enough, saplings review tool is just a very slow performing POC (though with a really good UI c…

I think it’s great that there is more than one project in this space. Sapling is pretty cool too, though I haven’t used it as much.

And yeah, the lack of good review tooling is certainly a big issue.

Re: Steve's Jujutsu Tutorial

#56

Post by steveklabnik »

swiftcoder wrote: post #39

> I also heard friends rave about "stacked diffs" but struggled to understand what exactly was going on there. Nothing I read or conversations I had have clicked. I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.

For me, my git brain is very low level. And none of them ever explains what actually happens under the hood, or how that was different than branching…

With some respect, I think “rebase centric workflow” doesn’t really cover it: I use rebasing heavily with GitHub. A “trunk based development where all branches are rebased before merge so there’s never merge commits, please add to commits and rebase the branches in response to review comments” development style is still very rebase centric, but not stacked.

You also have to remember (though there’s no reason you should know this) that GitHub came out of the community I was heavily involved in at the time of its birth. I’ve been using GitHub for longer than most people, and so the PR-style workflow has been the air I’ve breathed for so long, it can be hard to understand other things at first. I had used subversion before git, but didn’t really understand much about it.

Anyway, that’s just a roundabout way of saying that I think this space is super interesting because these tools are so flexible that they can be used in so many different ways, and it’s easy to assume that “how you use git” is some sort of shared experience when that’s not really true.

Re: Steve's Jujutsu Tutorial

#57

Post by steveklabnik »

swiftcoder wrote: post #51
arccy wrote: post #42

Earlier quoted context omitted.

because it's a name that describes the technical implementation, not the end user experience

Maybe the problem here is that there aren't any open tools implementing the user experience, because I'd say it's exactly the opposite - that it is implemented using rebase under the hood is entirely secondary to the user experience of "stacking" changes on top of one another.

This is a major issue for sure. Like a big enough one that if I was still doing major open source work, I’d be working on that.

Re: Steve's Jujutsu Tutorial

#58

Post by steveklabnik »

klauserc wrote: post #30

Been using jj at work for months now. In colocated mode, JetBrains IDEs even retain some if their VCS integration. The ability to easily work on top of an octopus merge and then push changes "down" into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners). The auto committing behavior is a bit we…

Full agreement on both “it feels weird” -> “how do people ever tolerate the old way” as well as the auto commit behavior being one of those things. In fact I probably over-index on that specifically when talking about jj. I thought I’d hate this because I love git’s index. Turns out that by getting rid of the index, jj has a better index than git does, but that sounds insane at first!

Re: Steve's Jujutsu Tutorial

#60

Post by steveklabnik »

ZoomZoomZoom wrote: post #22

Would be great if it was Pijul that got Steve's attention. Sometimes it's all you need to achieve a lot.

I’ll just be honest with you: Pijul never really caught my interest, but I always felt pretty neutral about it until I started noticing the project authors acting very snide and aggressive on here. That is not something I want to be around these days, and so I doubt I’ll ever try Pijul.
Post reply on HN