My team has a mix of software developers and scientists, and version control has been messy in the past. We're trying to do better, which leads me to ask this question.
We have a central codebase for a subset of projects that includes code for different tools all sharing common algorithms. Let's call that U1. There are fragmented tools disconnected from this codebase that should one day be integrated into it, because of common algorithms and other aspects of them.
A fragmented tool, let's call it F1, is probably not going to be merged into U1 for quite a while, but we still need to add it to version control. A scientist has been developing it on their PC, backing up snapshots, but we want a better backup/record system than that, thus the need for version control. Should F1 be stored as a branch in the same repo as U1, or if not, then where should F1 be stored?
On the one hand I'd say no to that question because F1 is not actually a branch of U1, it is essentially a separate tree. On the other hand, F1 is very similar to U1 in some ways and is just an extension of what U1 does. Someone looking for F1 would reasonably look in the same repository as U1. My concern with storing F1 as a branch is that we've had problems before with 'disconnected branches', branches that were committed with no ancestral relation to anything else in the repository. Obviously the best thing to do is merge F1 into U1 and call it a day, but I'm wondering where we should version control F1 until that happens.