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

Jujutsu and Radicle

radicle.xyz

Post reply on HN
Print view View original

61–70 of 97 posts

Re: Jujutsu and Radicle

#61

Post by JoshTriplett »

gpm wrote: post #34
hju22_-3 wrote: post #30

Earlier quoted context omitted.

Do you know of something that's good for what people tend to misuse Git submodules for? A multi-repo workspace thingamajig.

I think what I'd like for that is a mono-repo with better support for subsetting instead of a multi-repo with better support for unioning. I understand that Google (and may some of the other fangs) have tooling like that internally - but I haven't had the pleasure of using it.

That doesn't help if you actually need those repositories to exist separately.

For instance, consider the problem of having an external Open Source project your company maintains or heavily contributes to, and which also has common libraries shared with internal non-public work. Or, the same problem applies if you have a downstream Open Source project that needs to incorporate and vendor an upstream one but easily contribute changes upstream.

Some folks do this by generating the external repo as a filtered version of an internal monorepo, but that's awful in so many ways, and breaks the ability to properly treat the external repo as a first-class thing that can merge PRs normally. It leads to workflows where people submitting PRs feel like their work gets absorbed internally and maybe eventually spit back out the other end, rather than just being merged.

Re: Jujutsu and Radicle

#62

Post by gpm »

IshKebab wrote: post #49
stouset wrote: post #24

Earlier quoted context omitted.

This was the thing that stopped me from giving jj a shot for the longest time, but it turned out to be a complete non-issue. Definitely don't turn it off! The "aha" moment you might be missing is that you should consider your latest revision to just be the staging area. `jj commit -i` (shorthand for `jj describe; jj split -i`) is effectively `git add -i; git commit`. If you're worried about accidentally pushing unfin…

Say I check out a branch (or bookmark or whatever). I compile it. Some stuff doesn't work. I add some debug printfs. Compile it again. Ok I'm done now. In git I can just revert all the changes and I haven't modified anything important. In `jj` won't I have actually added all of those debug printfs to the top commit of that branch? Now I have to manually revert the edit? As I understand it, the answer is "aha, but you…

The default command you should reach for with jj to checkout a branch is `jj new branch` which creates a new commit to store your debug prints. You shouldn't do a two step process where you can forget the second step in the first place.

That said, if you do for whatever reason run `jj edit branch` instead (which enables the case you are discussing), jj will have snapshotted the previous change so you can still automatically revert the debug prints using

   jj evolog; jj restore --from old_commit_id

Re: Jujutsu and Radicle

#63

Post by gpm »

JoshTriplett wrote: post #61
gpm wrote: post #34

Earlier quoted context omitted.

I think what I'd like for that is a mono-repo with better support for subsetting instead of a multi-repo with better support for unioning. I understand that Google (and may some of the other fangs) have tooling like that internally - but I haven't had the pleasure of using it.

That doesn't help if you actually need those repositories to exist separately. For instance, consider the problem of having an external Open Source project your company maintains or heavily contributes to, and which also has common libraries shared with internal non-public work. Or, the same problem applies if you have a downstream Open Source project that needs to incorporate and vendor an upstream one but easily co…

Is the pain with publishing a subsetted version of the internal monorepo anything but a tooling limitation where things like pushing into that that subsetted version, and merging changes made on the subsetted version, aren't automatic because our tools don't natively understand subsets?

It would require forge integration, but I'd like a world where I could make a PR to `company/open-source-subdir` and the company could merge that PR and that was that without any extra steps because open-source-subdir is just a publicly published subset of the `company` repo.

Re: Jujutsu and Radicle

#64

Post by jcgl »

shayief wrote: post #36
vlovich123 wrote: post #14

Earlier quoted context omitted.

And do downstream PRs show just what changed or is the merge target against main which then just keeps accumulating differences? This is one of the strengths I appreciate about graphite which is that the PRs are always on the preceding branch but it knows that when you go to merge it should actually really retarget and merge against main.

Gitpatch author here. Gitpatch attempts to build a Git hosting with native support for patches and commit-based review system, where each commit is its own patch. It's also smart to handle force pushes and can update or reorder patches as needed.

Gitpatch looks really great. And I greatly appreciate you listing out alternatives.

Do you have any plans to allow for self-hosting?

Re: Jujutsu and Radicle

#65

Post by typpilol »

diarrhea wrote: post #44
JimDabell wrote: post #7

I’ve started using Jujutsu recently and was surprised at how low friction it was to switch. If you’re like the author and keep hearing about it without giving it a shot, I suggest you just sit down and try it – it’s a lot less effort than you might expect.

One of my favorite features of jj is file watching. Once set up, jj will snapshot the repo on every filesystem event. This means on every file save, you get a git commit! It provides arbitrarily fine-grained commit history, and works across all tools (not just your IDE). I set it up in the config and it has "just worked" ever since. The result is that `jj evolog -p` will show detailed history of your actions. But all…

Wouldn't you end up with like 1 million commits in a decent size projects really quickly?

Re: Jujutsu and Radicle

#66

Post by JoshTriplett »

gpm wrote: post #63
JoshTriplett wrote: post #61

Earlier quoted context omitted.

That doesn't help if you actually need those repositories to exist separately. For instance, consider the problem of having an external Open Source project your company maintains or heavily contributes to, and which also has common libraries shared with internal non-public work. Or, the same problem applies if you have a downstream Open Source project that needs to incorporate and vendor an upstream one but easily co…

Is the pain with publishing a subsetted version of the internal monorepo anything but a tooling limitation where things like pushing into that that subsetted version, and merging changes made on the subsetted version, aren't automatic because our tools don't natively understand subsets? It would require forge integration, but I'd like a world where I could make a PR to `company/open-source-subdir` and the company cou…

No, it's not just a tooling limitation. Or, at least, not one solvable just by having forges expose public subsets of private repos. That might partially solve the simplest case of `company/open-source-subdir`, if the company trusts the forge tooling to handle subsetting and to not expose more than they want, but it doesn't solve the more general problem.

Consider the case where the repositories are owned by different entities, for instance, or have different governance. For instance, Project X needs to vendor Project Y, and have a few downstream patches that they're working on upstreaming.

Right now, the two major options include:

- Use a submodule. Experience all the pain of submodules.

- Use some tooling to fold the repo into your own repo. Extract commits from it when you want to upstream. Experience all the pain of not having the original commits and the ability to easily pull/merge/cherry-pick/rebase, plus pain when you make changes across that repo and other code.

Re: Jujutsu and Radicle

#67

Post by IshKebab »

gpm wrote: post #62
IshKebab wrote: post #49

Earlier quoted context omitted.

Say I check out a branch (or bookmark or whatever). I compile it. Some stuff doesn't work. I add some debug printfs. Compile it again. Ok I'm done now. In git I can just revert all the changes and I haven't modified anything important. In `jj` won't I have actually added all of those debug printfs to the top commit of that branch? Now I have to manually revert the edit? As I understand it, the answer is "aha, but you…

The default command you should reach for with jj to checkout a branch is `jj new branch` which creates a new commit to store your debug prints. You shouldn't do a two step process where you can forget the second step in the first place. That said, if you do for whatever reason run `jj edit branch` instead (which enables the case you are discussing), jj will have snapshotted the previous change so you can still automa…

Ah interesting. That makes sense, thanks!

Re: Jujutsu and Radicle

#68

Post by steveklabnik »

typpilol wrote: post #65
diarrhea wrote: post #44

Earlier quoted context omitted.

One of my favorite features of jj is file watching. Once set up, jj will snapshot the repo on every filesystem event. This means on every file save, you get a git commit! It provides arbitrarily fine-grained commit history, and works across all tools (not just your IDE). I set it up in the config and it has "just worked" ever since. The result is that `jj evolog -p` will show detailed history of your actions. But all…

Wouldn't you end up with like 1 million commits in a decent size projects really quickly?

These are entirely local, and can be GC’d.

Re: Jujutsu and Radicle

#70

Post by nchmy »

stouset wrote: post #45
sestep wrote: post #42

Earlier quoted context omitted.

I really like all the concepts and have only heard good things, so I tried it but wasn't able to figure out how to use it as effectively as I can use Git. Specifically, I use VS Code and do a lot of stuff with the IDE's builtin support for selecting specific parts of files to stage, and I was hoping to be able to do something similar for jj split. I asked the Jujutsu Kaizen devs on Discord and they said that isn't cu…

As far as I know right now, no editors have great built-in support. As a heavy CLI user of (previously) git and now jj, selecting changes graphically is genuinely the one thing I’m envious of. The TUI that jj uses for interactive changes, `scm-record`, is fine but not great. It gets the job done but it could be so much more. Getting really good diff and conflict editor support into VS Code, Zed, et al is going to be…

jjui is what you're looking for. Incredible TUI

https://github.com/idursun/jjui

Post reply on HN