HN comments are hard, but essentially, if you have a dependency tree like this:
/ A \
-- B - Megamerge
\ C /
There is nothing stopping you from doing this:
/ A - D \
-- B ----- - Megamerge
\ C - E /
Where E stacks on C and D stacks atop A. In the case above, A-E are revsets of either 1 or more commits. JJ doesn't care if they are or not. You'd generally bookmark the revset on the final "commit" as the pointer.
/ features/add-widgets
/ / features/add-widget-integration
/ A - D \
-- B ----- - Megamerge
\ C - E /
\ \ feature/add-new-page
\ feature/rework-navigation
In the example above, let's say you rework the navigation. You could have it exist alongside the navigation rework, but changes are you don't want to do the work twice. You just say "hey, this depends on the nav rework" and so it's there inside of the repo.
The thing is there is another way to do this where you end up with 4 different parents in a megamerge and your nav rework touches the megamerge and your new page is yet another revset is just a fork off of it. But yeah... JJ gives you a lot of flexibility in this manner.
HN comments are hard, but essentially, if you have a dependency tree like this:
There is nothing stopping you from doing this:
Where E stacks on C and D stacks atop A. In the case above, A-E are revsets of either 1 or more commits. JJ doesn't care if they are or not. You'd generally bookmark the revset on the final "commit" as the pointer.
In the example above, let's say you rework the navigation. You could have it exist alongside the navigation rework, but changes are you don't want to do the work twice. You just say "hey, this depends on the nav rework" and so it's there inside of the repo.
The thing is there is another way to do this where you end up with 4 different parents in a megamerge and your nav rework touches the megamerge and your new page is yet another revset is just a fork off of it. But yeah... JJ gives you a lot of flexibility in this manner.