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

I see a future in jj

steveklabnik.com

Post reply on HN
Print view View original

301–310 of 336 posts

Re: I see a future in jj

#301

Post by 1718627440 »

steveklabnik wrote: post #268
1718627440 wrote: post #217

Earlier quoted context omitted.

> There's no need for staging or stashes in jj. What the JJ developer seam to misunderstand is, that the index and stashes are a feature to improve the users workflow. You can bypass the index with commit -a, giving you JJ behaviour and you can commit just fine instead of using the stash. The stash is like some backlog of temporary commits and also supports saving the index separately. When you don't care about this,…

So this is as an opinion I had when I heard about jj too. But the thing is, jj supports this workflow very well, and in fact better than git, because the stash/index is just a normal commit, not a separate feature. In fact, the most popular jj workflow is closer to the git add -p workflow than it is git commit -a. I’d argue more jj developers work this way than git developers do in git, even.

JJ has a backlog of temporary commits? That's a stash under another name.

Re: I see a future in jj

#302

Post by 1718627440 »

steveklabnik wrote: post #244
1718627440 wrote: post #215

Earlier quoted context omitted.

That's called a merge commit. You can even group them further by creating merges of merge commit. It requires you to merge in the right direction though.

That doesn’t really hide them in the UI though.

--first-parent? --simplify-by-decoration? It doesn't hide them by default yes. It does have several paragraphs with all the ways how to simplify the history.

Re: I see a future in jj

#303

Post by jonstewart »

philipwhiuk wrote: post #239
jonstewart wrote: post #112

What I miss from the Perforce and Subversion days is committing directly to trunk in a team environment. Now everything revolves around PRs and lengthy code review. With direct commits to trunk, everyone was in a rush to get their commit in before someone else did, so they didn’t have to update and have conflicts. This made commits small, frequent, and usually well-scoped. What -sucked- was when you did need to do a…

> then that was work best done on a weekend I mean that's just toxic.

So was CVS!

Re: I see a future in jj

#304

Post by jonstewart »

cozzyd wrote: post #133
jonstewart wrote: post #112

What I miss from the Perforce and Subversion days is committing directly to trunk in a team environment. Now everything revolves around PRs and lengthy code review. With direct commits to trunk, everyone was in a rush to get their commit in before someone else did, so they didn’t have to update and have conflicts. This made commits small, frequent, and usually well-scoped. What -sucked- was when you did need to do a…

You can totally use that workflow with git.

I know but tell that to GitHub/Gitlab/BitBucket/etc.

Re: I see a future in jj

#305

Post by baby »

steveklabnik wrote: post #288
baby wrote: post #170

That's exciting! Have you guys looked into sappling from Meta as well? It looked really cool the last time I looked into it but never tried to use it much.

One of ERSC's cofounders left Meta for this, so it's known by the team very well. Sapling and jj are similar for sure.

I would guess rain must be aware of it too! rain are you here :P

Re: I see a future in jj

#306

Post by coastalpuma »

steveklabnik wrote: post #271
coastalpuma wrote: post #238

Earlier quoted context omitted.

Agree, the feature of commutative patches just seems obviously superior? Not sure why there's a critical mass to adopt jj over Pijul apart from jj's git backend.

I think this gets at one of my original comments in this thread: I think the reason of commutative patches has communication issues. The benefits touted are very abstract. The problems I’m aware of it solving are mostly theoretical problems for working devs, and so the message hasn’t landed. If I were interested in advocating for these tools, I’d be trying to find a message that does resonate.

> The benefits touted are very abstract

Not really? From someone's post here a year ago:

> The real innovation of a lot of these alternative DVCS systems is that they free the state of the source from being dependent on the history that got you there. Such that applying patches A & B in that order is the same as applying B' & A' -- it results in the same tree. Git, on the other hand, hashes the actual list of changes to the state identifier, which is why rebasing results in a different git hash id.

Anybody who's wrestled with reordering/rebasing git history or has done git archaology is able to understand this benefit.

From Pijul's site:

> Pijul is the first distributed version control system to be based on a sound mathematical theory of changes

After years of grudgingly tolerating using a deployed prototype for a VCS, yes, I want the mathematically sound alternative.

All that being said, I do wish you the best, because truly, I am tired of git and JJ does seems like an improvement.

Re: I see a future in jj

#307

Post by steveklabnik »

1718627440 wrote: post #301
steveklabnik wrote: post #268

Earlier quoted context omitted.

So this is as an opinion I had when I heard about jj too. But the thing is, jj supports this workflow very well, and in fact better than git, because the stash/index is just a normal commit, not a separate feature. In fact, the most popular jj workflow is closer to the git add -p workflow than it is git commit -a. I’d argue more jj developers work this way than git developers do in git, even.

JJ has a backlog of temporary commits? That's a stash under another name.

Not exactly, but sorta. You don't need to write a description for a commit, and it doesn't need to be on a branch, and things are auto-committed. So if I'm working on something, and then I "jj new" to start something else somewhere else, I can trivially come back to what I was doing. You're right that's a stash under another name: a commit. But the key is, because it's not a special separate thing from a commit, I can use any command that works on commits to work on my stash. We've unified two things into one thing. And that's useful.

Re: I see a future in jj

#308

Post by steveklabnik »

jrockway wrote: post #295
jjmarr wrote: post #151

Earlier quoted context omitted.

I'm banned from force-pushing at work so this makes jujutsu a challenge for me. The workflow still functions, it just requires me to manually update bookmarks.

I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me. I personally feel like your employer's policy is unusual for PR branches. Other people force pushing? Bad. Force-pushing to `main`? Bad. But force pushing to your own branch when you can delete it and re-create it? Just a waste of…

Github's behavior when branches are force pushed makes some places ban it, that might be your parent's situation.

Re: I see a future in jj

#309

Post by jjmarr »

jrockway wrote: post #295
jjmarr wrote: post #151

Earlier quoted context omitted.

I'm banned from force-pushing at work so this makes jujutsu a challenge for me. The workflow still functions, it just requires me to manually update bookmarks.

I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me. I personally feel like your employer's policy is unusual for PR branches. Other people force pushing? Bad. Force-pushing to `main`? Bad. But force pushing to your own branch when you can delete it and re-create it? Just a waste of…

> I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me.

Correct.

It makes sense to me because it leaves a linear history of git commits in response to comments on a PR which makes code review easier. We squash and rebase at the end.

> Just a waste of your time for no real reason. I wonder what the justification is.

We used to be on Gerrit, which I found better for code review as I could stack a bunch of minute changes together. I probably had 50-100% more productivity on Gerrit before my team made the switch.

Unfortunately, the industry standard is GitHub PRs. My team wasted a ton of time onboarding people to Gerrit and even after onboarding, less than 5% of people understood stacked changes enough to use them effectively.

Since force pushing/rebasing messes up GitHub PRs it was banned.

If you have suggestions for alternative code review workflows on GitHub I'm happy to hear them, but ideally they could be incremental.

Re: I see a future in jj

#310

Post by mpalmer »

CuriouslyC wrote: post #286
mpalmer wrote: post #274

Earlier quoted context omitted.

if I make a plan which causes the project to be identical to its state 5 years ago, the edit distance is zero, but in no way can you call that a measure of history

You're still thinking in graphs. That plan would already exist in the database, you would just be making it a build target instead of whatever new plan was targeted before.

It seems as though you've come up with a model for representing source code repos in terms of a data model of your own design, solving problems of your own choosing. But what you describe is not a version control system in the generally agreed upon sense of the word.
Post reply on HN