I have a project folder that has multiple duplicate files that are named slightly differently to create "backups". So I have "file1.txt" and "file1 backup.txt". Is there a preferred method to capture the old history when I make the folder into a git repository?

3 Answers 3


With out a lot of messing about, the simplest option is to just commit the full project folder as the first commit, then delete all of the backup files and finally commit your 'cleaned up' copy. That way you can access the copies of the old files any time you want, but they don't normally clutter up your working directory.

If you really want to try and reconstruct your history you might try using some of the techniques from Charles Bailey's Lightning talk at this years ACCU Conference:

  • Massaging Hunks: The Awesome Power of git add -p (p89).

Don't put them in at all! I don't know the exact way in Git, but in SVN you just don't add them to the repository. With a version control system you don't need another history - it just adds complexity.

You should alway commit to source control as soon as possible. Generally this is as soon as you have working code. The more often you commit, the less likely those other history files will be needed.

  • Yes I am well aware of committing to source as early as possible. Unfortunately I received these projects from someone who doesn't use source control or understand it. So I'm trying to get it into Git for my own sake. If it was me from the beginning this wouldn't be an issue Jul 15, 2011 at 14:16
  • This doesn't quite answer the question. The OP has a non-versioned folder with several files representing different versions of the same document. Using Git, he wants to keep the different versions, and therefore the history of the document, without having separate files. If he doesn't put them in at all he loses the existing history when he converts to Git. You're right that you should always use source control, though; at the very least, you should do so the moment you find yourself creating "file1 backup.txt".
    – Ant
    Jul 15, 2011 at 14:17

If you know what backups were taken when, you can do the following (manually :/):

  1. Create a git repo and commit the first version of the file(s)
  2. Copy the next newer backup version of the file(s) over the original(s) and commit those.
  3. Continue until you're at the latest version.

Cons: takes a long time if you have many files

Pro's: you can draw your history as you seem fit. Multiple file updates can be in one commit, or each file can have its own commit to update it, and everything in-between. You get a clean, condensed, complete history and all the backup versions are stored neatly in source control. You can do exactly what @Mark suggests in his answer, but that's even more fine-grained than file/backup based commits.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.