|
|
|
|
|
|
by ashenke
498 days ago
|
|
|
So I've been hovering around jj for a while, trying to understand how it works, without suceeding in having a good mental model around it.
I looked at this megamerge workflow and it's the first one that "clicked" for me (even though I'm not sure I understand the magic behind jj absorb, but I'll look into it).
One thing though is that I don't quite understand how it would work in the context of a real git repo. Let's say I work on two branches, main and feature1, I'd create a [merge] commit that is has the two bookmarks as parents. But if after a fetch main has new changes, do I need to discard the current [merge] and recreate it again ? I can't find a way to just say "Update the parents so they track these bookmarks".
I just tried it on a real repo, working on a change in a branch, then on a change on another branch, then adding a third branch I needed to work on that was not a parent yet, but this seems like a lot of boilerplate to always recreate my megamerge setup so I think I'm missing something |
|
|
Just to be clear, `jj` stores all of its stuff in a real git repo. I know you probably meant "using git instead of jj" but I wanted to point that out because it means that you can just go look at what it does. I will say that sometimes that can be confusing, and I'd be very careful running git commands that modify history inside that directory.
So for example, here's a simple mega merge:
the first commit after the root is bookmarked as `main`, our three changes are on top of it, with a mega merge.I've used a colocated repo, so the `.git` dir is at the top level, so we can just run `git log`:
So this is the initial state.Let's say that we pull down our remote, and main has changed, as you've said. There is a new commit on top of it.
We can simulate this in jj. (q is valid because we have so few changes there's no others that start with q yet)
here's our log in `jj`: and in `git`: So now we get to the issue: git would want us to rebase every one of these branches individually. When we rebase A (19d713aab65d0e572994634b2487ce7637d6752a) on top of main@origin (c8318f5fd641a9b271b67e90e7ca1c465b1a92da), well: (don't do this in a real repo, since this is an example I'm okay with trashing things, I even made a copy of the repo before doing this) We only get one branch. So what we'd have to do is go back and fix up every single branch here, including our merge. And so yeah, you can do it, but it's a giant pain in the butt. And for the children, you really need --onto, so you'd end up doing something like for every branch. HOWEVER, git has introduced --update-refs, which can automate this. But it's from 2022, and my Ubuntu is a bit old, and so I cannot actually try it out.That allll being said, I also don't know how well --update-refs does with the mega merge commit itself.
> this seems like a lot of boilerplate to always recreate my megamerge setup so I think I'm missing something
I mean, the entire thesis here is that stuff is easier in jj than it is in git: it doesn't mean you're missing something it means that git can be a bit clunky sometimes.