3 ms·
Git’s rerere functionality should address this, right? https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere
by neandrake 2y ago
Git’s rerere functionality should address this, right?
https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere
- fallingsquirrel 2y agoI'm not a heavy jj user. But as I understand it, git-rerere is bolted on top and not well integrated. It just stores resolutions locally on each machine in .git/rr-cache. You need extra steps to share resolutions between contributors. https://stackoverflow.com/questions/12566023/sharing-rerere-cache https://stackoverflow.com/questions/12566023/sharing-rerere-... In jj, resolutions are first-class objects—treated the same as any normal commit, pushed/pulled like normal, etc.
- keybored 2y agorerere is indeed bolted on. Linus doesn’t want people who he pulls from to back-merge, i.e. to merge at “random points” from him into their trees to keep up to date. But what about merge conflicts? Then he has to deal with them. So then he might begrudgingly ask them to back-merge right before making a pull: a real zig-zag pattern. First-class conflicts would solve all that I think.
- stouset 2y agoIn theory yes. In practice I’ve had it enabled since it was first released and it helps… some?
- martinvonz 2y agoIn some cases, yes, but I think the way jj handles conflicts is easier to follow. You can see the conflict resolution in `jj diff` and you can rebase it like a regular commit. rerere's state is harder to understand, I think. See https://github.com/martinvonz/jj/issues/175#issuecomment-1079831788 https://github.com/martinvonz/jj/issues/175#issuecomment-107... for some more discussion.