Building a git repository from a set of manual archives

Question

I am dealing with an application that has been created without a proper content management system. Instead, the source files have been saved into a ZIP archive and backed up every time a new version was released.

I’d very much like to get this project into a git repository to get a proper picture of the changes over time, but I’m far from clear how to do this as I have only ever created brand new git repositories or worked with existing ones.

It would be simple to just create a repository from the most recent archive and work from there, but how do I include the history of changes?

Answer 1

It would be simple to just create a repository from the most recent archive and work from there, but how do I include the history of changes?

Pretty easy. There are two ways to approach this depending on how clean the codebase is from one ZIP archive to another: Cumulative UnZIP Commits or Clean Up After Each Commit.

Cumulative UnZIP Commits: UnZIP, Commit, UnZIP another, Commit Another, Etc…

The solution is to first create a git repository based on the oldest archive, commit it, then add the subsequent/progressively-newer stuff, commit that and so on and so on. So for example, let’s say you have three archives that are named/dated as follows:

• archive_20150801.zip
• archive_20150804.zip
• archive_20150806.zip

Now I would begin by unZIPping archive_20150801.zip and creating the initial git repository based on that. Then I would unZIP archive_20150804.zip and drag/copy—or just unZIP in place—so that stuff overwrites the older archive_20150801.zip and so on. Ditto with archive_20150806.zip.

Clean Up After Each Commit: UnZIP, Commit, Delete, UnZIP another, Commit Another, Delete Another, Etc…

But if you want to be extra accurate in your merging of newer files with older files in each ZIP archive, I would recommend doing this:

1. UnZIP an archive and commit it.
2. Then after that commit is done, manually—not via git rm—remove all the files from the directory that contains the repo. Be sure not to remove the git-specific stuff like .git, .gitignore and such.
3. With that done—and a relatively empty directory in place—unZIP the next archive and place it’s contents into the git repository directory.
4. Now with new files in place do a git add -A and do a new commit.
5. With that done, go back to step one for the next ZIP archive you wish to add to the mix.

The benefit of that “commit stuff, delete stuff, add new stuff, commit new stuff” method is you won’t end up with stray files that might have only existed in an early version of the code in the final repository. Each commit is a pure reflection of what that ZIP contains and not a cumulative pile of files and directories expanded on top of each other.

Keeping Commit Dates Straight

As for keeping some semblance of a date/time history, you can do some fancy footwork and force actual git commit dates to conform to actual archive dates as explained in this Stack Overflow answer. But I personally find that overly complex and risk-prone; I prefer to keep tasks like this as simple as possible. Instead I would set a commit message that clearly states what each commit is like:

Commit of 2015-08-01 ZIP release archive.

That way you can easily know what the source of the archive commit in the future by just browsing the commit comment history.

I’ve done this myself for old archives I managed via this old-school, “copy-the-directory-and-create-an-unmanaged-ZIP-archive” method and it’s a pain, but it helps in the long run to retain some semblance of a coding history for a project.