How to commit new code to Git and forget the old code?

Question

Basically there is a repo on GitHub that contains code that's being used. We actually started completely from scratch and rebuilt this particular project with a completely new structure since it was a "done by those idiots that worked here before that couldn't find their butt with both hands" kind of thing. You've been there, right?

Anyway, after it's rebuilt I really want to use the same repo because the project name is what it should be, but I want to start with a whole new codebase while keeping the history of the old. Is that possible? Kind of like version 2.0. I've never had to do that before so I don't know. I am guessing maybe I have to create a new repo for it or rename the original and start over, but I thought I'd ask. I couldn't find anything on the interwebs about it so here I am asking you.

UPDATE: What I ended up doing was sort of what Casey said in a comment - I would give you credit for the answer but I can't on a comment. I renamed the original repo and created a new one for the new code. Pretty simple.

Answer 1

Anyway, after it's rebuilt I really want to use the same repo because the project name is what it should be, but I want to start with a whole new codebase while keeping the history of the old. Is that possible?

You can commit the changes as normal using the normal git commit, with git add and git rm. Git doesn't really care how much code you change.

You'll probably want to do the v2 development as its own branch until it's ready. Rewrites usually take a very, very, very long time and are rarely satisfactory straight out of the box. You'll want to keep open the option of continuing development on and releasing of version 1 while you're working on version 2. Then when v2 is ready, merge it in to the main branch.

The first commit in the v2 branch might simply delete everything, but rewrites rarely throw everything out, so you might want to take a more nuanced approach that changes things in pieces and harvests important and hard won details and business logic from the old code. And if you want to retain compatibility you'll want to keep the old tests as regression tests. And if there's and persistent data like user accounts or billing information or the like, you'll have to port that data to the new application so having the old code and data schema around for reference will be useful.

---

If they're incompatible with each other you might even wind up releasing both in parallel as version 1 users don't want to rewrite everything to use version 2. In fact, if version 1 and 2 are incompatible, you're really making a whole new project that is related to the original in concept and name only (and maybe some of the same people). It might be more polite to your users to start a new project called "WhateverYourProjectIsCalled2". That way anything that uses version one can go on using WhateverYourProjectIsCalled and new users, or existing ones that want to switch, can use WhateverYourProjectIsCalled2.

Since many of the same people will be working on both projects, you can use a Github organization to own both of them and manage the collective permissions without having to duplicate all that.

There's plenty of examples of the different ways of dealing with this. While Perl 5 was an 80% rewrite of Perl 4, it only had minor incompatibilities and retained the same code base and community. In contrast Perl 6, a complete and incompatible rewrite of Perl, completely split off from Perl 5 in all aspects: new code, new repository, new community, even a new license.

On the flip side, Python 3 introduced some big incompatibilities with Python 2 but remained "Python". This caused a bit of chaos in the Python community as the vast amount of existing Python 2 code will not run on Python 3 and vice-versa; they are mutually incompatible. Now Python 2 and Python 3 are developed and released in parallel and Python libraries have to choose which one, or both, to support. It's all "Python" despite no longer being able to run code in common.

---

Which route you choose depends on what you're developing. If it's a user application you can probably safely keep it in the original repository, users will adapt to the new version, but you'll still want to hang on to the old tests (at least the blackbox tests) to make sure it still works and you're not reintroducing old bugs.

If it's a programming library or has anything that things programmatically depend on like a plugin API or a web API, you should probably split it into a new project to avoid introducing a massive and sudden incompatibility on your users.

The nice part about Git is if you choose one strategy you can change your mind later. A branch can be split out into its own repository (complete with history), or a separate repository can become a branch. I'd recommend starting with a branch until you're sure this rewrite is going somewhere.

---

Finally, rewrites usually fail. They're extremely high risk for a large number of reasons that I won't get into. There's usually a reason "those idiots that worked here before that couldn't find their butt with both hands" did what they did. Sometimes it's a bad reason. Sometimes its a good reason. Sometimes it was a good reason but isn't anymore. Developers looking to rewrite an old system often find there's a lot of minute details they didn't take into account.

Instead, consider refactoring the old code in steps. It's much lower risk, it retains the hard won knowledge of "those idiots" about details of business logic and bug fixes, it forces you to examine and understand everything the old system does in detail, and everything continues to work as you make small(er) and more controlled changes.

Answer 2

If you commit new code over the top of the old version, you will have the old version/code in the history and all changes that were made of all time. As a measure of safety why not copy/clone the current (legacy) code into another repository or at least a "History" branch so you can access it whenever needed. You can always run "git log" on your codebase as an extra measure to see what and when you/others changed things. https://githowto.com/history