icorbrey

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