tags:

views:

47

answers:

3

I need to set up a project for git revisionning. The project team has kept backup snapshots of about 40 of the current 200+ numbered builds. What would be the most efficient way to bring that into a new git repo?

My thinking is the obvious one: use the oldest backup to init the repo, then walk through the 40 snapshots one by one, for each of them:

  • find files in the snapshot that are newer than in the repo
  • move those file to the project under revision
  • commit changes

Is there anything smarter?

FWIW, it's a a C++ Mac project using Xcode 3, that added at a later stage a Windows version using Visual Studio 2008. All the source code is kept in sync between the Mac and PC versions.

A: 

As mentioned in the comments, you can simply replace one directory with another, and make a git -A to combine:

  • "git add .", which looks at the working tree and adds all those paths to the staged changes if they are either changed or are new and not ignored, it does not stage any 'rm' actions.
  • "git add -u", which looks at all the currently tracked files and stages the changes to those files if they are different or if they have been removed. It does not add any new files, it only stages changes to already tracked files.

Actually, if you have 40 different directories, you can execute that command in each one of them, if you specify the GIT_DIR and GIT_WORK_TREE environment variables.
Except than you can specify them directly in the command line (which is more convenient for GIT_WORK_TREE, since it will change 40 times)

Initialize a git repo anywhere you want (/path/to/my/repo) and make 40 git add like:

git add -A --git-dir=/path/to/my/repo --work-tree=.
VonC
+1  A: 

If the backups can be numbered sequentially, it becomes really easy. Write a script that will loop through them, commit, and tag with the version. I've done this for a project I took over that had no VCS set up.

Daenyth
+2  A: 

Git (effectively) stores the complete source tree for every single revision. If there are differences between commits, it figures that out from those complete copies. It does not depend on any particular operations in the working copy.

So as the others have already written, you can just blow away your working copy, unpack the next snapshot into it, and git add -A && git commit. You don’t have to do anything more complicated than that.


Tip: blowing away the working copy in bash:

( shopt -s extglob dotglob ; rm -r !(.git*) )
Aristotle Pagaltzis