Hacker News Reader

Comment by wakamoleguy | Hacker News Reader

I have been trying to use jj for a couple months now, but hitting some friction with my company’s GitHub PR workflow. Specifically, after the PR is merged, the next time I fetch I always end up with a ton of conflicts. It gets hard to clean them up, so I often end up abandoning all mutable commits to start fresh.

I feel like I’m doing something wrong, as I haven’t seen this mentioned in any tutorials, but I don’t know what! :-/

View on HN

That's really odd, maybe the tree is somehow messed up? I've never had this problem. What's conflicting?

Can you try it on a fresh clone and see if it still happens?

Maybe it’s based on whether the GitHub merge is a squash, rebase, or plain merge? Or do folks usually manually perform the merge with jj?

It shouldn't matter, under the hood the tree is the same for both. I don't know why jj would complain but git wouldn't, hm.

for me, squash merges are enforced on github, and usually results in some weird / empty commits if i rebase a local stack after pulling in changes with part of the stack merged.

It’s also possible that I start my next task without remembering to create a new diff first. That might explain the conflict when the original commit becomes immutable?

I wonder if they've got files tracked by git-lfs. `jj` doesn't handle those yet.

Are you making MRs from other branches in the same repo, or are you making e.g. main to main MRs from your own fork?

I build a few diffs off of my local main, create and push a bookmark, and then create a PR back to main from that bookmark.

I’ve been using jj for a few months now and still love its workflow, but I keep running into the same problem you mentioned. The advantages of jj far outweigh this issue, so I’d really like to figure out a clean way to avoid these conflicts.

What does git think of the tree after you pull? Does everything seem fine to git, but jj shows a conflict?

Reply on news.ycombinator.com