views:

27

answers:

1

I made an open source release based on a codebase which contained unfinished refactoring and other misc changes. Unfortunately it turned out to take a lot more work than expected and so now I am considering re-releasing the last stable codebase, and make a new branch that would contain any changes I did since.

How would you go about that, short of manually checking every single file one by one?

Thinking aloud:

Would it be possible somehow to initialize git on the old codebase, then create a new branch, then copy over the 'refactoring' codebase on top of the stable codebase (in my local git repository), and then git would detect all changes if I type 'git st' ? Would there be substantial flaws in that?

PS: - the open source release is very recent, nobody contributed yet which would make it possible to re-release in a better format - my dilemma here, is that I didn't use version control until sometime after I started the refactoring..

+1  A: 

What you suggested would work fine, though this may be easier and avoid messing with your working copy.

  1. git init in your old codebase
  2. copy the .git directory into your new, refactored code directory
  3. git checkout -b new-branch
  4. git commit -am 'refactoring'
kubi
Hmm I have no idea what this does but I'll try it! If I copy the .git alone that means I have committed everything first right? Are you making a branch from the existing changes? That's something I wanted to do often as a Git newb, because I often forget to create a branch BEFORE starting some changes...
faB
Yeah, you commit everything first in your original repository, before you copy the .git directory. What this does is it makes git think that you suddenly did all your refactoring edits on top of the commits from the old codebase. And YES, this does create a new branch for you.
kubi
Aye thanks again that was pretty smart, git status would show all changes, and then a git diff could show the changed code in any specific file. Great tip.
faB