Perforce report to Bitbucket - possible to split up into multiple repos?

[Allen Huffman]

We had a Perforce repo that contained many directories for different projects. We migrated it to Bitbucket late last year, and I still have one repo with all those project directories.

A coworker was in the midst of moving things in to individual repos before he moved on to greener pastures, and now I am revisiting this project.

I really only care about version history for the individual files. For example, we might have:

• Windows/Host
• Boards/Board1
• Boards/Board2
• Board/Bord2

There are many times when we made a chance to add a message to Board1, Board2 and Board3, and also support to use that message in the Windows host program. As such, the Perforce check in history (and newer Bitbucket commits) will have a check in that goes to different folders that ideally we'd split up.

If my path was Development/Project/Boards/Board1/src, inc, etc.

Ideally I might want to make a new repo called "Board1" that has those files at the root. But I suspect that will break all the file history, since they are linked to a path/place rather than the file.

Suggestions on what to read up on in the Bitbucket/Git documentation would be greatly appreciated.

Thanks!

[Aron Gombas _Midori_]

It sounds you were using a so-called monorepo approach with Performance. If you were happy with that, you can continue the same approach also with Git!

There are many articles  with pratical tips on the web, just Google for "monorepo git":

• https://about.gitlab.com/blog/2022/09/06/speed-up-your-monorepo-workflow-in-git/
• https://www.gitkraken.com/blog/git-multi-repo-vs-git-mono-repo
• https://github.blog/2021-11-10-make-your-monorepo-feel-small-with-gits-sparse-index/

First tip: Git supports "sparse checkout" to clone only a subdir of the monorepo.

[Allen Huffman]

I guess I know it works under Git since that's how we've been using it since we migrated to Bitbucket, but...

The way Perforce works, where you just "get" the files you want to work on, it wasn't a big deal.

The way Git works, where it pulls down every file and all versions (or so it seems), it's not ideal. I don't like having to pull down hundreds of thousands of files to work on a project that is made up of five source files and a few headers. I'll look in to sparse checkout.

I still do not like the "kitchen sink" approach of a monorepo (yay, I learned a new term today) but a sparse checkout might solve my major issue with it.

[Allen Huffman]

Side thought: I wondered about cloning the repo multiple times, then just deleting anything I no longer wanted to keep. I suspect there is a way in Git to jettison the deleted folders so they don't live on forever.

But, if I did that, and ended up with just one folder:

Development/Project/Boards/Board1

...I couldn't move that back to the root without breaking all the history links, could I?