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

Jujutsu (jj), a Git compatible VCS

tonyfinn.com

Post reply on HN
Print view View original

101–110 of 117 posts

Re: Jujutsu (jj), a Git compatible VCS

#101

Post by edflsafoiewq »

stouset wrote: post #100
edflsafoiewq wrote: post #97

Earlier quoted context omitted.

I don't believe I've ever pushed a WIP commit. Count that to the benefits of stashing I guess. I don't consider any of this a problem, but why don't you tell me how your preferred tool does it.

So when I say there a problems with stashing, you suggest wip commits. When I point out problems with wip commits, we go back to stashing? jj needs neither because everything in your working copy is already part of a commit. You can’t accidentally push unfinished changes because jj will complain if it hasn’t been described (given a commit message). If you need to move changes between commits you don’t need to stash b…

Stashing vs WIP commits have pros and cons. I've never hit any of these problems you're pointing out, so I don't have any particular strong opinion about which one you should use.

I can see that being nice I guess.

If jj's stashes are just regular commits, don't you have the problem where you accidentally push a stash just like you push a WIP commit?

Re: Jujutsu (jj), a Git compatible VCS

#102

Post by stouset »

edflsafoiewq wrote: post #101
stouset wrote: post #100

Earlier quoted context omitted.

So when I say there a problems with stashing, you suggest wip commits. When I point out problems with wip commits, we go back to stashing? jj needs neither because everything in your working copy is already part of a commit. You can’t accidentally push unfinished changes because jj will complain if it hasn’t been described (given a commit message). If you need to move changes between commits you don’t need to stash b…

Stashing vs WIP commits have pros and cons. I've never hit any of these problems you're pointing out, so I don't have any particular strong opinion about which one you should use. I can see that being nice I guess. If jj's stashes are just regular commits, don't you have the problem where you accidentally push a stash just like you push a WIP commit?

It’s not like these are git’s only pain points. Git is practically the poster child for software that’s difficult and confusing to use.

Re: Jujutsu (jj), a Git compatible VCS

#103

Post by edflsafoiewq »

stouset wrote: post #102
edflsafoiewq wrote: post #101

Earlier quoted context omitted.

Stashing vs WIP commits have pros and cons. I've never hit any of these problems you're pointing out, so I don't have any particular strong opinion about which one you should use. I can see that being nice I guess. If jj's stashes are just regular commits, don't you have the problem where you accidentally push a stash just like you push a WIP commit?

It’s not like these are git’s only pain points. Git is practically the poster child for software that’s difficult and confusing to use.

I don't think so. Like the OP, my everyday git usage is pretty straightforward. So "maybe this thing you do every once in a while could be a little nicer" doesn't feel very compelling.

Re: Jujutsu (jj), a Git compatible VCS

#104

Post by mamcx »

steveklabnik wrote: post #98
mamcx wrote: post #91

Earlier quoted context omitted.

> looks more complicated and verbose than regular gi Is Git not verbose and complicated? It is like the poster child of it among ALL THE OTHER options in his space! --- I was a heavy user of mercurial, I learned it in a day or two, then maybe only had one or 2 major complications for years. I use git now for 'social' pressure reasons, and despite I use it more heavily than hg, i need to check stuff every week. And ha…

You’re like the perfect audience for jj. Give it a try with some of your git repos. If you hate it, easy to go back to git afterwards. But I think you’ll like it.

Ironically the major thing that blocks me is the need for more adoption.

I predict I will have enough of it in the next mess of trying to stack PRs or resolve another rebase of 30 steps.

Re: Jujutsu (jj), a Git compatible VCS

#105

Post by mamcx »

cupofjoakim wrote: post #2

I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my…

One of the devs I hire tries unsuccessfully for 2 weeks to merge, rebase, fix, and refactor pr of moving a lot of things.

I did it in half a day.

Git is bad.

Re: Jujutsu (jj), a Git compatible VCS

#106

Post by emacsen »

eikenberry wrote: post #96
stouset wrote: post #94

Earlier quoted context omitted.

You live with those files showing up as untracked because it was easy and convenient to do so with git. If git auto-added them from the get go, you would have used a pattern in your personal or project gitignore to skip them, or you would have put them into an ignored tmpdir, or you would keep them on a separate branch if you intend to make them part of the repo. None of these steps would have felt painful or out of…

Cool. You've convinced me. A small change in workflow + easy cleanup sounds like it addresses most of my concerns. Though if I were to adopt jj I'd still probably just turn off the feature at first until I saw where I could have used it in practice. I'm going to wait and see for a bit myself. I'm pretty comfortable with git.

The way jj tracks changes isn't a feature you can turn off AFAIK. Maybe you can, but if you can, you shouldn't. This is fundamental to the jj internals and workflow.

As someone who also kept a lot of files in their repo that went untracked, it was a small adjustment. Add to my .gitignore, untrack the files, and done.

Re: Jujutsu (jj), a Git compatible VCS

#107

Post by stouset »

emacsen wrote: post #106
eikenberry wrote: post #96

Earlier quoted context omitted.

Cool. You've convinced me. A small change in workflow + easy cleanup sounds like it addresses most of my concerns. Though if I were to adopt jj I'd still probably just turn off the feature at first until I saw where I could have used it in practice. I'm going to wait and see for a bit myself. I'm pretty comfortable with git.

The way jj tracks changes isn't a feature you can turn off AFAIK. Maybe you can, but if you can, you shouldn't. This is fundamental to the jj internals and workflow. As someone who also kept a lot of files in their repo that went untracked, it was a small adjustment. Add to my .gitignore, untrack the files, and done.

You can disable automatically adding untracked files to the repo, but you can't disable it from automatically incorporating changes to tracked files. I believe GP was talking about the former.

Re: Jujutsu (jj), a Git compatible VCS

#108

Post by eikenberry »

stouset wrote: post #107
emacsen wrote: post #106

Earlier quoted context omitted.

The way jj tracks changes isn't a feature you can turn off AFAIK. Maybe you can, but if you can, you shouldn't. This is fundamental to the jj internals and workflow. As someone who also kept a lot of files in their repo that went untracked, it was a small adjustment. Add to my .gitignore, untrack the files, and done.

You can disable automatically adding untracked files to the repo, but you can't disable it from automatically incorporating changes to tracked files. I believe GP was talking about the former.

Yes. It was specifically adding untracked files automatically.

Re: Jujutsu (jj), a Git compatible VCS

#109

Post by yuppiepuppie »

stouset wrote: post #93
yuppiepuppie wrote: post #86

Earlier quoted context omitted.

But I don’t see the complaints that were claimed. I help people as well. They learn, and we move on. If they don’t learn then we have another problem to solve. I will admit there is occasional call where I have to get someone out of a twisted pretzel, but that is few and far between.

You don’t deal with rebase conflicts? You don’t ever unstash to the wrong branch? Or to the right branch, but it was changed and now it’s applied uncleanly? You don’t ever want to go fix a previous commit? You don’t ever need to do linear work that gets merged one piece at a time into the trunk? All of these things (and others) can be worked around with varying levels of annoyance ranging from just living with it to…

With a proper workflow and communication, only the first one (rebase conflicts) is a semi-regular occurrence (once a month). The others I have never had to do while working on a team. We establish a clear way of working and everyone abides by it.

And before you say well this doesn’t work with a bigger team, my team is 8 and the org is 50 on the same codebase. At “google scale”, I understand this might not be the same case.

If someone has to go out of that workflow to fix a previous commit on main, they submit a pr on top of latest.

Again, I don’t see the major complications here. It seems to me to be fixing a communication issue in an org more than anything.

Re: Jujutsu (jj), a Git compatible VCS

#110

Post by steveklabnik »

edflsafoiewq wrote: post #101
stouset wrote: post #100

Earlier quoted context omitted.

So when I say there a problems with stashing, you suggest wip commits. When I point out problems with wip commits, we go back to stashing? jj needs neither because everything in your working copy is already part of a commit. You can’t accidentally push unfinished changes because jj will complain if it hasn’t been described (given a commit message). If you need to move changes between commits you don’t need to stash b…

Stashing vs WIP commits have pros and cons. I've never hit any of these problems you're pointing out, so I don't have any particular strong opinion about which one you should use. I can see that being nice I guess. If jj's stashes are just regular commits, don't you have the problem where you accidentally push a stash just like you push a WIP commit?

> don't you have the problem where you accidentally push a stash just like you push a WIP commit?

Because jj doesn’t require commits to be on a branch, and the equivalent feature (bookmarks) don’t automatically advance, if you created a new commit to stash some stuff, the name wouldn’t move to it, and so when you push nothing would happen.

Post reply on HN