icorbrey

Really the main point of Spindle is inherently to prevent locking you into using Tangled's CI solution.

The way that spindles work is that they basically just get events from repos when something happens, like a push or whatever. The spindle, if it's going to respond, eventually responds with what the results were, if any. If it looks like a spindle and quacks like a spindle, it's a spindle.

Tangled's CI happens to do this by way of receiving an event, looking at your Tangled workflow files, and using those to determine when it should actually run your CI. There's no reason it has to stay like that though.

I personally am planning on implementing a Tangled spindle that, instead of looking at Tangled workflow files, looks at just my Nix flake and builds and deploys things based on that. It's a very open solution, everything is just a protocol, there's no lock in.

Tangled's Spindle itself, as a product that conforms to the informal Spindle protocol, is pretty decent. You put in Nix dependencies and some scripts and when it should run, and you get out working CI. I have no complaints about it

If you inspect a GitButler repo with JJ you can see that it's topologically identical actually! https://bsky.app/profile/isaaccorbrey.com/post/3m33wrahz4222

Fwiw I've not had this experience, I use megamerges in teams of 8+ devs without much issue

Re: commit dates, fundamentally those always change when rebasing because you're rewriting the commit object, but we don't touch the author date unless you explicitly reset it with metaedit

Thanks!

This is something you have to generally handle manually since absorb won't squash hunks with ambiguous targets, but I typically stack these branches and accept the dependency. I have had instances where this has backfired a little bit re: ordering but thankfully with JJ and the very patient little man in my computer named Codex it's easy to reorder them and end up with the same diff

Awesome! Tbh other than GitButler idk where I'd even start if I had to recreate this with vanilla Git

Look man life gets busy and I'm horrible at accepting "good enough" lol

Fwiw I generally solve this by using `jj commit` instead of `jj desc` unless I'm specifically targeting something that isn't my working copy. Technically it violates the "we want commands to be orthogonal" guideline we use to write Jujutsu (otherwise this would indeed be `jj desc; jj new`) but as a habit it's never let me down

Not sure on `jj init`, but yeah colocation is default as of I believe 0.34

Indeed, though I don't think it can create fixup commits if that's what you're looking for. However, it might work great for that if you pair it with jj-spr: https://github.com/LucioFranco/jj-spr

Megamerges are awesome, but what really makes them magical is when you start using `jj absorb`, which automatically splits and squashes your commit down to the nearest unambiguous commits and leaves anything that doesn't have an obvious place to live