Take the 2-minute tour ×

I've developed code locally and taken a fairly regular snapshot whenever I reach a significant point in development, e.g. a working build.

So I have a long-ish list of about 40 folders, each folder being a snapshot e.g. in ascending date YYYYMMDD order, e.g.:-

  1. 20100523
  2. 20100614
  3. 20100721
  4. 20100722
  5. 20100809
  6. 20100901
  7. 20101001
  8. 20101003
  9. 20101104
  10. 20101119
  11. 20101203
  12. 20101218
  13. 20110102

I'm looking for a script to import each of these snapshots into GIT. The end result being that the latest code is the same as the last snapshot, and other editions are accessible and are as numbered.

Some other requirements:

  • that the latest edition is not cumulative of the previous snapshots, i.e., files that appeared in older snapshots but which don't appear in later ones (e.g. due to refactoring etc.) should not appear in the latest edition of the code.
  • meanwhile, there should be continuity between files that do persist between snapshots. I would like GIT to know that there are previous editions of these files and not treat them as brand new files within each edition.

Some background about my aim:

  • I need to formally revision control this work rather than keep local private snapshot copies.
  • I plan to release this work as open source, so version controlling would be highly recommended
  • I am evaluating some of the current popular version control systems (Subversion and GIT) BUT I definitely need a working solution in GIT as well as subversion. I'm not looking to be persuaded to use one particular tool, I need a solution for each tool I am considering. (I haved posted an answer separately for each tool so separate camps of folks who have expertise in GIT and Subversion will be able to give focused answers on one or the other).

The same but separate question for Subversion: Script/tool to import series of snapshots, each being a new revision, into Subversion, populating source tree?

share|improve this question

closed as off-topic by MichaelT, Bart van Ingen Schenau, Dynamic, gnat, Dan Pichelman Apr 22 at 16:33


  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – MichaelT, Bart van Ingen Schenau, Dynamic, gnat, Dan Pichelman

If you are looking for actual code (script) as part of your answer then you should be asking this question on SO. If you are asking for the concepts on how to acheive your goal then I would suggest editing your question. –  Walter Jan 5 '11 at 12:46
add comment

2 Answers

up vote 3 down vote accepted

Since Git is a content management system, it won't consider a file as new because you add it again: if it has the same (or almost the same) content, it will link its history with previous version of the same file (or actually detect it has been renamed).

The idea is to:

  • create a git repo outside of all your directories.
  • go into each one of your directories.
  • git --git-dir=/path/to/git/repo/.git add -A in order to add/remove all files from the current directory compared to the external working tree of your Git repo.
    The idea is to use each directory content as the working directory of a git repo which is setup elsewhere, outside of any of those directory.
  • git commit -m "a comment"
  • git tag -m "a comment" myTag
share|improve this answer
On the git add -A operation, see stackoverflow.com/questions/572549/… –  VonC Jan 5 '11 at 12:33
+1 Looks like just about all I need - thanks. I'll need to set up GIT on my machine to try it out. If it works out then I would hope to accept this answer. –  therobyouknow Jan 5 '11 at 12:53
I assume that this answer handles the case where files get removed in later snapshots as a result of re-factoring? Also, a useful feature that you mention is the ability to detect the same file but renamed - something Subversion is weak on I believe (feel free to correct me). –  therobyouknow Jan 5 '11 at 12:54
@Rob: yes, the git add -A will remove from the index any file that is no longer present in the working tree. But that file is removed because of a refactoring (and is actually renamed with a slightly different content), git will be able to make the link between the removed file and the one after refactoring. –  VonC Jan 5 '11 at 12:56
@Rob: not sure about the "languages of code" part: if a file disappear, but another with (almost) the same content appear elsewhere, it is enough for Git to make the link. Whatever language of code is used. (Or maybe I misinterpret this expression somehow?) –  VonC Jan 5 '11 at 13:09
show 4 more comments

Simplest case, I can think of...

  1. Create a git repo/folder, copy the first snapshot into the repo and name it src or something suitable.

  2. Next, Add, Commit the files/folders to repository.

  3. Now, remove the folder and copy the next snapshot in it's place. (naming it as you did the last snapshot.

  4. Repeat from stage 2.

You can check the git status between each snapshot, this will show up any files it considers missing, so you can mark them as removed from the repository.

Roughly speaking that will do what you need.

share|improve this answer
Thanks - although this answer is pitched at the "Simplest case, (assuming no files were removed from one snapshot to another.)" - I think it actually accounts for that scenario actually because you then say "You can check the git status between each snapshot, this will show up any files it considers missing, so you can mark them as removed from the repository." - so it should cover removed files. –  therobyouknow Jan 5 '11 at 12:58
Yes, it will, I just don't explain how you might automate this. (e.g. parsing the results of git status) - but I removed that note from the answer anyway :) –  Slomojo Jan 5 '11 at 13:06
+1 for confirming that it handles removed files, @Slomojo. –  therobyouknow Jan 5 '11 at 13:36
BTW the Subversion method would be very similar to this. –  Slomojo Jan 5 '11 at 21:55
+1 Answer because it outlines the approach. Accepted @VonC because they give commands to issue. –  therobyouknow Jan 6 '11 at 16:31
add comment
