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?
asked Jul 15, 2011 at 13:48
Add a comment
|
3 Answers
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).
answered Jul 15, 2011 at 14:13
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.
answered Jul 15, 2011 at 14:01
-
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".– AntJul 15, 2011 at 14:17
If you know what backups were taken when, you can do the following (manually :/):
- Create a git repo and commit the first version of the file(s)
- Copy the next newer backup version of the file(s) over the original(s) and commit those.
- 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.
