1

Back before I had heard of the wonders of version control, I kept projects in folders like "project x 1.0", "project x 1.1", "project x 1.2", etc. There's tons of redundancy in this approach, so I'd like to use git to consolidate and version control the system for the future.

What's the best way to do it? I assume I should start by running git init on "project x 1.0", but then how can I consolidate the other folders into the project as new commits? (I'm still very new to git)

3 Answers 3

4

I'd start by creating a new empty directory, creating a repo in it with git init, and doing a first commit with just a .gitignore file or something.

Then copy all the files from your first revision to this new dir, git add and git commit. This will give you your first real commit.

Then copy/overwrite all the files with the contents of your second revision. git add, git commit.

You can repeat that as much as you want. The very first step isn't really necessary, you could do that in your first revision's directory. But doing so in a fresh directory allows you not to change anything at all in your backups, so you can start from scratch again if you want to improve/tweak the process, without risking losing anything in your old directories.

3

There's a good book for git called Pro Git. There's a section on how to migrate from a custom structure as well. (See Custom Importer). It's a little bit harder, but if you have a lot of history then that would be the best way.

The other way is to do:

# initialize a new repository
git init .
touch .gitignore
git add .
git commit -m "initial commit"

# copy all the files to working directory
cp -R backup_v01/* .
# stage all the files
git add .
# make the first commit
git commit -m "v0.1 from backup"

# remove all files
git rm -r *
# copy all the files to working directory
cp -R backup_v02/* .
git add .
git commit -m "v0.2 from backup"

This can be optimized but this script can easily be understood. You need to remove all old files from the repository before updating the contents because otherwise you would have some old deleted files hanging around.

Of course the whole thing can be made into a script (repo.sh):

#!/bin/bash
REPODIR=$1

# initialize a new repository
git init $REPODIR

cd $REPODIR
touch .gitignore
git add .
git commit -m "initial commit"

while read DIR
do
  # remove all files
  git rm -r *
  # copy all the files to working directory
  cd ..
  cp -R $DIR/* $REPODIR/.
  # go back to repo dir
  cd $REPODIR
  # stage all the files
  git add .
  # make the first commit
  git commit -m "$DIR from backup"
done

The folder switching is necessary to make it work with relative paths.

You use it by sending all the folder paths to the script and specifying the repository directory (it must not exist):

# let's say all the backups are in this folder
# and there are no other folders

# test whether everything is in correct order
ls -d */ | sort

# verify that there is no repository directory
rm -rf REPO_DIR

# pipe the folder listing to the script
ls -d */ | sort | repo.sh REPO_DIR
2

Another way would be to, after initing and committing in your first project version, move the .git repository directory from your 1.0 copy to your 1.1 copy, add those changes (use git add --all to notice deletions) and commit, then move it to 1.2, and so on.

This works because Git does not keep any information about the state of the repository outside of the .git directory, so it doesn't care that you're moving .git rather than replacing the files. However, if you have e.g. files that you want to ignore by .gitignore, this would require you to add the ignore file to each project version individually.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .