Resolving GitHub repository merging and project linking issues in v0

[hyperdimension]

This is probably going to be an absolute worst case scenario, but here goes.

v0 created a branch of an already branched repo in a project that I completed 2 days ago. This project was forked from its main project and I created a new branch so I can work on an UI overhaul.

I can no longer merge changes up to the main branch.

Since I can’t merge from the branched branch, I went into terminal locally and did a

git checkout Main-dev  
git pull  
git merge ui-overhaul --allow-unrelated-histories  
git add .  
git commit  
git push origin Main-dev

Github repo main branch updated properly. Great. The build failed in v0 for the original project that was forked for this overhaul and was tied to the main-dev repo.

So I decide to just start a new project and link the repo and let it rebuild. I’ll update my supabase keys. No harm, no foul. Right? Right?

Wrong. I can only create a new repository when starting a new project….

Okay. Maybe I can just update one of the existing two projects already attached to that github repo? Nope. There isn’t a single option available to change the current repo.

No more push or pull. No more options. I may very well be missing something here but what exactly am I supposed to do in this situation?

What happened to the control? I get this definitely solves a problem a lot of people have where they didn’t push and lost info or changes, and it was a real pain point. But using a bazooka to kill a fly and not worrying about the blast radius? I don’t mean to speculate but I’m kind of annoyed that I’m ready to merge a ton of hard work (and money) and launch something I’ve been working on, and I’m just sort of dead in the water.

Can someone please provide some guidance?

P.S. - The npm run build error is pointing to a bunch of paths that are now being seen as duplicate from the merge. The forked project I did the work in runs fine, and even if I resolve this build error, I still cant change any of my repos from within v0. I can still only rely on it’s branched repo pushes and nothing else.

[system]

Did you know there’s another category dedicated to v0 topics? A human should be here soon to help, but the answer may already be available even faster in one of these other posts.

Our docs are a great place to start.

What is v0? | v0 Docs

We also have a walkthrough to help guide your workflow.

Become a v0 expert

Getting Started Using v0 is like chatting with a frontend engineer, who takes in your design guidelines and creates an application for you. A common workflow with v0 is putting in design files and images to scaffold your application and then use text prompts to nudge v0 into creating your perfect application. Remember, just like any other AI tool, the quality of the output that v0 generates depends on the quality of the prompt or instructions you input. So, it’s important to be clear, descripti…

And these recordings can give you a look at v0 features and strategies in action shown by our Community:

https://community.vercel.com/tags/c/events/42/v0

[pawlean (Pauline P. Narvas)]

Hey, @hyperdimension!

Thank you for the detailed post. I’m sorry about this! It seems super frustrating.

Here are a couple of things I recommend doing.

If you can still access the v0 chat interface for the broken project:

Paste the exact build error into the v0 chat and say: “I manually merged branches and now the build is failing with duplicate path errors. Please scan the file system, identify the duplicate files/configs causing the build failure, and delete or merge them to fix the build.”

v0’s Agent has the power to delete files and fix configs that you might struggle to find manually.

v0 is designed to be the “source of truth.” When you use standard Git commands (like merge --allow-unrelated-histories) outside of v0, you are changing the “history” in a way that v0’s internal tracker doesn’t understand.

Pro-tip: In the future, try to let v0 handle the merging via its own “Merge” or “Deploy” buttons whenever possible, or only push “standard” commits to the branch v0 created, rather than trying to merge disparate branches into it.

[hyperdimension]

Sorry for the wall of text if this is read by anyone *
*
I appreciate you taking the time to look into this. I’d never take aim at the messenger as someone who lives in support as well.

There are really two problems here.

A function was removed. Ripped unceremoniously from users without the option or ability to review the changes to the system, merge/pull/commit any updates one last time, and try to learn the new lay of the land.

I definitely would not say my workflow is the best because I jump between v0, cursor, and my own direct changes I make in Supabase and as I learn. But When tools work a certain way and I’m working within the constraints of those tools, I and others create their own workflow that…works.

Being able to make visual changes in v0, push to github, pull the new code into cursor for some codex reasoning and review, push to github, pull the changes into v0…..etc it extended ownership. The sense that this belongs to you so use it how you please. You control where and when the code goes and doesn’t go. Removing that ability mid process is frustrating, even if the bigger picture was to ensure changes didn’t get dropped due to user error or otherwise.

Now…I’m sure what you suggested would work, but I personally don’t feel that I should have to lose all that progress I technically paid for, then pay again for the privilege of having v0 fix an issue that the company itself made. In fact, if I screwed up something myself I’d likely follow the exact steps you listed. v0 was already decent at fixing issues when directed properly. But the way I work personally doesn’t lend itself well to having a platform determine when I should and shouldn’t push commit, merge my code, or living in so many branches and doing pull requests to main. Ya’ll could have if given some heads up and time to adjust (And if I missed that when only refreshing my project page for a month then my bad I guess). It should at least have been an option for users to square up their process before it changed.

I fixed my particular issue by promoting the ui-overhaul branch to main/default in github. v0 seems like it had no choice but still see that as a branch and pushes directly to what is now functionally my main… And when I make a change outside of v0 its allowing me to pull those changes. Which I find entertaining. (wonder if any one QA’d for that)

The other build failed errors, I fixed in cursor. But I also ultimately abandoned the v0 chat that had issues as the errors were not present in the forked one.

My issue was never the errors. It was that I lost the ability to push and pull at will.

I don’t even think the change was a bad one if I’m being honest. I think, like mine, there were enough edge cases and this was executed poorly for us. But I’m just the guy who dropped $238 dollars this month trying to build something for himself. And well, yknow, thats just like my opinion.

I’m more sorry that ya’ll have to deal with the backlash. But I’m happily working in Cursor for this leg of my project. I may be back for a side project i was planning to host here entirely. Or to do the UI design for another project.

Anyway. Thank you for getting back to me, Pauline. I do sincerely appreciate it.

Cheers

[pawlean (Pauline P. Narvas)]

Everything that is posted in this platform directly drops into our Slack channel with engineers so I appreciate the depth in feedback here.

I wanted to share that this was all relating back to this change:

v0

I also recommend reading this comment:

Bring back the pull/publish workflow in v0

Hey @pawlean — I was stressed for absolutely no reason. The issue? I didn’t understand the new workflow. Why? Because I didn’t read. Shame on me Once I actually took the time to read, understand, and do some simple research and verification (AI is very helpful here, by the way—breaking things down, checking updates, and explaining them in plain English), it clicked. This new update is actually better. It compartmentalizes the workflow. Instead of one super long chat conversation…

@hyperdimension

But I’m just the guy who dropped $238 dollars this month

Please feel free to raise a refund request at Help and link back to this post.

Thanks again and we hope to see you here again!

[hyperdimension]

Super appreciate the further context. And ultimately for this specific project the update landed in the middle of, its not the right fit. Keeping everything in one platform is a nightmare for my personal projects. This was ultimately the reason I cancelled my Bolt subscription. Their “Bolt Databases” rollout (which is Supabase with internal connections and styling) as default and making it near impossible to migrate that DB into your own Supabase account. Then losing functionality when connecting your own Supabase project DB within bolt.. They did a roll out, made announcements, but imagine all of a sudden you try to make a change to an RLS policy and the connection breaks, and their suggestion was transferring your DB project to bolt . I believe they worked out all the kinks now, but I moved that project from v0 to bolt FOR the ability to have it make direct changes to Supabase within the project. And now that one is in cursor as well.

Moving towards a platform where everyone can develop, host, maintain, etc, is 100% the right move. I’m just not the right user for that model for my things. I want to develop on bolt, v0, cursor. Host websites in Netlify ,host apps on Render. Maintain my own DB’s in Supabase and Firebase. Maintain my own analytics in Google. Etc.

But still, one of the 3 projects I have here will live entirely within Vercel’s eco system because it makes perfect sense. And I agree with the platform vision.

If any one is receptive to feedback I only have one suggestion.

Please consider an onboarding period for new features. Brand new users get the new feature/system immediately. Existing users get a notification and documentation of changes, the option to opt in immediately, a deadline of a week or a few days before its switched over by default. I definitely would have appreciated the heads up, documentation, and chance to adapt.

I already got a refund for something unrelated and this issue only really ruined my workflow. I won’t be requesting a refund for this thread but I thank you again for being the great human that you are in this community.

Thanks!

(I’ll mark your latest comment as solution so this post can fall into the abyss.)