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

331–336 of 336 posts

Re: I see a future in jj

#331

Post by 1718627440 »

pm215 wrote: post #317
1718627440 wrote: post #300

Earlier quoted context omitted.

The transparent thing would be to put everything into the index, and configure all the commands to autoupdate the index. This is what happens with the merge conflict, because there is no benefit having resolved merge conflicts not already in the index. So the merge conflicts already do what you want, the other commands need to be modified.

That isn't what I want, though. I don't see any point in the index as a construct -- I am happy with changes being either (a) not in any commit, just in the working directory or (b) in the most recent commit. Somewhere lurking in the middle is just confusing.

I constantly have something different in the index, that is neither in the commit nor in the workspace, and I find that useful.

Re: I see a future in jj

#332

Post by KingMob »

1718627440 wrote: post #328
steveklabnik wrote: post #322

Earlier quoted context omitted.

I am saying a feature was removed, yes. But what I'm saying is, the things you use that feature for can still be accomplished. It's just not accomplished via a dedicated feature, but as an effect of how other features work.

Yeah and I am saying that you could do that as well with Git. Git just also does have that feature and a lot of users like to use that, but you don't need to.

git and jj are functionally equivalent in this respect, yes, but it's all easier in jj. It all becomes one concept and one command set, instead of three different ones.

The git features of stashing/staging are removed, but they're superfluous given how jj works. You don't need or want them, and keeping them around would only give people two ways to do the same things.

Re: I see a future in jj

#333

Post by 1718627440 »

KingMob wrote: post #332
1718627440 wrote: post #328

Earlier quoted context omitted.

Yeah and I am saying that you could do that as well with Git. Git just also does have that feature and a lot of users like to use that, but you don't need to.

git and jj are functionally equivalent in this respect, yes, but it's all easier in jj. It all becomes one concept and one command set, instead of three different ones. The git features of stashing/staging are removed, but they're superfluous given how jj works. You don't need or want them, and keeping them around would only give people two ways to do the same things.

> You don't need or want them,

> give people two ways to do the same

This is where I am disagreeing. I do want them.

for, while and goto achieve the same and are the same thing under the hood, yet they convey different semantic and you choose between them for different tasks, because they are more suited for different things.

stashes and commits achieve the same and are the same thing under the hood (both are commits), yet they convey different semantic and I choose between them for different tasks, because they are more suited for different things.

All in software is about different abstractions, that all fundamentally do the same thing.

> but it's all easier in jj

You can literally use commits instead of stashes in Git and guess what: it's the same as treating any other commit. Here JJ and Git are the same. You can also do stashes in Git, when you want temporary commits that are put into a "todo" list.

Re: I see a future in jj

#334

Post by KingMob »

1718627440 wrote: post #333
KingMob wrote: post #332

Earlier quoted context omitted.

git and jj are functionally equivalent in this respect, yes, but it's all easier in jj. It all becomes one concept and one command set, instead of three different ones. The git features of stashing/staging are removed, but they're superfluous given how jj works. You don't need or want them, and keeping them around would only give people two ways to do the same things.

> You don't need or want them, > give people two ways to do the same This is where I am disagreeing. I do want them. for, while and goto achieve the same and are the same thing under the hood, yet they convey different semantic and you choose between them for different tasks, because they are more suited for different things. stashes and commits achieve the same and are the same thing under the hood (both are commits…

These are all good points, and if it fits how you think about the problem, git is clearly right for you.

I think for me, the unification of concepts, and simplification of DX, wins out. I like being able to use the same set of commands for all three. I didn't miss staging or stashes at all when I switched.

Re: I see a future in jj

#335

Post by codethief »

steveklabnik wrote: post #298
codethief wrote: post #297

Earlier quoted context omitted.

> we have to offer real value here If I may make a suggestion here: Allowing PRs to be stacked, i.e. allowing commits to be reviewed individually, like in Sapling, would be FANTASTIC. EDIT: See also the link in this comment: https://news.ycombinator.com/item?id=45675335

This is something that I am comfortable saying is absolutely going to be the case.

That's great to hear! Looking forward to ERSC!

Re: I see a future in jj

#336

Post by 1718627440 »

martinvonz wrote: post #240
1718627440 wrote: post #219

Earlier quoted context omitted.

git rebase --update-refs

That won't update sibling branches

It won't update (sibling) branches, that are checked out.

      --update-refs, --no-update-refs
           Automatically force-update any branches that point to commits that
           are being rebased. Any branches that are checked out in a worktree
           are not updated in this way.

           If the configuration variable rebase.updateRefs is set, then this
           option can be used to override and disable this setting.
Post reply on HN