I’ve built a relatively large system, and while doing so, I realised I needed to test an idea, so I created a second task to develop that idea: a more complex data model, basically, to create more flexibility for the end user.
Initially, when I was working on it, it kept asking me, when I’d finished a given version, to merge back into the main, but I wasn’t finished. I kept going because I wanted to create something I could show people to get their approval on whether this separate version was the right way to go.
Now I have a problem: the merge to main branch button isn’t appearing. I’ve spoken to the agent about it and asked him what to do. It suggested building another task, which I got it to do and approved, which built some of the functionality across, not all of it. With the main version, I’ve intentionally kept it, I think, 95% the same as it was when I pulled off this version.
Has anyone else experienced this issue where it stops asking you to merge, and if so, did they come up with a solution to get it back?
The merge button doesn’t vanish at random. It disappears when Replit can no longer work out a clean merge path, and your description says why.
When you forked the task it branched from a specific checkpoint of main. The merge-back button only shows while a clean three-way diff is possible between your fork, that original checkpoint, and current main. Two things in your story break that. The fork changed the data model, which is a big structural diff, and main didn’t stay frozen either. “95% the same” means it moved 5%, and that can be enough to lose the clean common base. Once there is no clean ancestor to merge against, the button just stops appearing rather than showing you a conflict.
That is also why the “build another task to carry it across” route gave you partial functionality. It re-implemented from a prompt instead of merging, so it brought over what it noticed and quietly dropped the rest. Repeating that will keep landing you at roughly 80%.
The recovery is to stop treating it as an agent problem and treat it as a diff. Your fork’s code still exists in that task. Get the actual file-level differences between the fork and main and apply them deliberately. Handle the data model change separately from the app code, because that is the part a merge would have broken silently anyway, since existing rows don’t migrate themselves.
If you list which files the two versions disagree on, especially anything touching the schema, I can suggest an order to bring them over without wrecking the main version.