I often have "no changes" in my Codespaces, because I haven't committed then yet.
Would be nice, if Codespaces keeps the JJ change stored somewhere, so it isn't tied to the lifetime of the machine.
What I've learned from jj
11–20 of 140 posts
Re: What I've learned from jj
#12Jujutsu - I like the name.
I often see programming as going MMA with data, until you get what you want out of it.
Using brute force algorithms is going berserk, vibe coding is spamming summons in hope they get the job done, etc.
Re: What I've learned from jj
#13Like the author, I'd appreciate a stacked PRs approach , integrated with GitHub (unfortunately). E.g. `a → b → c → d` where I have PRs open for `b`, `c` and not yet on `d`, that are "linked" to the jj changes. So 1 change per PR or it could even be multiple. I've lately become a huge fan of git-spice, that just works .
Stacked PRs is clearly a nice workflow... except that forges like Github generally have really poor support for them.
I wish Github would just allow you to say "this PR depends on this other PR", and then it wouldn't show commits from the other PR when reviewing the stacked PR.
But as far as I know you can't do that.
Re: What I've learned from jj
#14[deleted]
Re: What I've learned from jj
#15Jujutsu - I like the name. I often see programming as going MMA with data, until you get what you want out of it. Using brute force algorithms is going berserk, vibe coding is spamming summons in hope they get the job done, etc.
Agreed, I'd just like to complement vibe coding feels like spamming retarded Mr Meeseeks hoping they get get the job done. It's _probabilistic programming_
Re: What I've learned from jj
#16Like the author, I'd appreciate a stacked PRs approach , integrated with GitHub (unfortunately). E.g. `a → b → c → d` where I have PRs open for `b`, `c` and not yet on `d`, that are "linked" to the jj changes. So 1 change per PR or it could even be multiple. I've lately become a huge fan of git-spice, that just works .
Stacked PRs is clearly a nice workflow... except that forges like Github generally have really poor support for them. I wish Github would just allow you to say "this PR depends on this other PR", and then it wouldn't show commits from the other PR when reviewing the stacked PR. But as far as I know you can't do that.
If you change the target branch it will only show commits that are against that. I wish GitHub did that automatically because it has the parent commit tree but when do you that you'll only see commits that diverge from the target branch/pr.
Is that what you want?
Re: What I've learned from jj
#17Earlier quoted context omitted.
Stacked PRs is clearly a nice workflow... except that forges like Github generally have really poor support for them. I wish Github would just allow you to say "this PR depends on this other PR", and then it wouldn't show commits from the other PR when reviewing the stacked PR. But as far as I know you can't do that.
If you change the target branch it will only show commits that are against that. I wish GitHub did that automatically because it has the parent commit tree but when do you that you'll only see commits that diverge from the target branch/pr. Is that what you want?
That works but depending on how you merge the PR, you end up needing to do a rebase on all of your future PRs.
I really wish 1PR = 1 commit with revision based diffs. Similar to gerrit.
Re: What I've learned from jj
#18It’s clear from multiple posts over years that jj has a better UX than plain git.
Why not just merge it into git?
Re: What I've learned from jj
#19Like the author, I'd appreciate a stacked PRs approach , integrated with GitHub (unfortunately). E.g. `a → b → c → d` where I have PRs open for `b`, `c` and not yet on `d`, that are "linked" to the jj changes. So 1 change per PR or it could even be multiple. I've lately become a huge fan of git-spice, that just works .
Stacked PRs is clearly a nice workflow... except that forges like Github generally have really poor support for them. I wish Github would just allow you to say "this PR depends on this other PR", and then it wouldn't show commits from the other PR when reviewing the stacked PR. But as far as I know you can't do that.
Another person has commented that you can do this, but it's a little known thing. git-spice automatically manages it for you too.
Re: What I've learned from jj
#20Earlier quoted context omitted.
Stacked PRs is clearly a nice workflow... except that forges like Github generally have really poor support for them. I wish Github would just allow you to say "this PR depends on this other PR", and then it wouldn't show commits from the other PR when reviewing the stacked PR. But as far as I know you can't do that.
If you change the target branch it will only show commits that are against that. I wish GitHub did that automatically because it has the parent commit tree but when do you that you'll only see commits that diverge from the target branch/pr. Is that what you want?
Not really. I've tried that with Gitlab, but it's kind of awkward. My PR isn't to merge branch B into branch A. For instance if the project owners see the PR for B and say "yeah great! I'll merge this" and press merge, it will just merge it into branch A and then close your PR!
It's a hacky workaround at best. I want proper support. I want Github to disable the merge button until the dependencies are merged. I want it to actually list the dependencies and link to them. I want the target branch to be `main`.
I think if they did those 3 things it would go 90% of the way. Too much to ask though clearly.