Depending on another topic

[Tomasvrba]

Hi! Big fan of this workflow, thanks for all the write up around it. It has been working great for us with our CI/CD.

One question about merging topics into other topics when they depend on each other.
Your recommendation is to:

create your topic and merge the other topic into it. This explicitly records the dependency relationship between the topics, and puts the commit resolutions (if any) on the right branch.

But

if topic B depends on another topic A that has not yet graduated to master, topic A may be merged into topic B. This complicates interactive branch rebases so this should be avoided when possible, however if necessary, git should handle this situation without too much problem.

Interactive rebasing to clean up commit history etc is an obvious pain point here, that would be nice to avoid.

But my main concern is this use case:
If Topic B depends on Topic A and both are in development, I merge Topic A into Topic B and do some work. But Topic A is still being developed and I need to pull in the newest features again into Topic B, a second merge commit in this case would complicate rebasing and history even more. What would be your thoughts in this case?

Instead of merging topic dependencies, wouldn't it be better to keep them rebased during development? And maybe only merge the dependency when it graduates by first getting rid of the depending commits:
git rebase --onto master topic-a topic-b
and then merge topic a into topic b to record the dependency?

While this is a solution, it's not the cleanest one imho, as it relies on best effort from everyone to rebase and merge correctly when necessary.

I'd love to hear any ideas for a better approach :)

[rocketraman]

Hi! Big fan of this workflow, thanks for all the write up around it. It has been working great for us with our CI/CD.

Great to hear!

If Topic B depends on Topic A and both are in development, I merge Topic A into Topic B and do some work. But Topic A is still being developed and I need to pull in the newest features again into Topic B, a second merge commit in this case would complicate rebasing and history even more. What would be your thoughts in this case?

Instead of merging topic dependencies, wouldn't it be better to keep them rebased during development?

Personally I agree and tend to operate this way myself, assuming this is what you mean: if developing on topic-b, I tend towards merging in dependent topics like topic-a as my first commit on topic-b. Even if I only realize topic-a depends on topic-b after I've committed a bunch of stuff into topic-b, I'll still use a rebase to rewind to master, merge in topic-a, and then add my topic-b commits on top. When topic-a has been updated, I'll either rebase topic-b so so that the latest version of topic-a is still the first merge commit, or occasionally if it has only changed in minor ways (and hasn't been rebased itself), I'll sometimes take a shortcut and just merge it at the head of topic-b.

I just find mentally that is easier to follow my topic history that way be ensuring my work is "on top" of any other major work.

Note also that with the existence of rebase -i -r (there is an issue open to document this here: #6) this is all quite easy to do!

And maybe only merge the dependency when it graduates by first getting rid of the depending commits:
git rebase --onto master topic-a topic-b

So here topic-a has graduated to master already? If so, yes, I'll often do this too, though its definitely not necessary. I won't do it as a rule, but really only if master has other things in it I want, and if topic-a has graduated, I no longer need it merged into topic-b.

and then merge topic a into topic b to record the dependency?

I might be misunderstanding you. If topic-a has graduated and you're rebasing topic-b, then this will be a no-op.

[rocketraman]

@Tomasvrba thoughts on my comments above?

[Tomasvrba]

Thanks for the input and the quick reply.
Agreed with everything and our workflow setup is also to keep all topic commits "on top" of other dependencies so it's easy to tell which commits actually belong to a certain topic.
At this point I think rebase with --rebase-merges is the way to go, I'll test it out with a situation from last week where we had about 5 topics that needed to graduate that all depended on each other in some way.

As to the last point where I mentioned git rebase --onto, no, topic-a had not graduated to master in my example, but topic-b was ready for graduating to next/pu for testing. But that's not a very good example anyway, since it depends on topic-a so topic-a needs to also be finished first in any case.