12

I inherited a project stored in CVS. The previous developer has massive un-committed changes in his working directory, including removal of a ton of files, that I would like to inspect. Here's my plan:

  1. cvs checkout the_project.
  2. Follow the remote cvs / local git workflow, initializing a git repo with the pristine state of the_project.
  3. Copy the new .git into the the other working directory.
  4. Presto! All the removals/changes show up as unstaged differences.

This initially looks like it's gonna work. Any major pitfalls I should worry about?

chreekat
  • 974
  • 7
  • 16
  • 1
    I believe this is the same as removing all the files from the Git working copy and pasting files from CVS repository. This should work and show you all the changes that have been made. – Tadeck Apr 17 '12 at 23:37

3 Answers3

5

I do something similar all the time. I use GIT to track multiple releases and multiple branches from a large SVN project. The project has ~200 SVN modules each in a subdirectory of 'src'. When I started the GIT repository, I checked out v9.4.4 of the project, did a 'git init' added .gitignore and .gitattributes, did a 'git add -A' and 'git commit -m 'v9.4.4'. Then I moved .git up out of the project and created a symbolic link to it. When the v9.4.5 release came along I checked it out, added a symbolic link to the now shared .git directory, added the .gitignore and .gitattributes, did a 'git add -A' and 'git commit -m 'v9.4.5'. At this point, I have one GIT repository symbolically linked from two directories.

With this setup you can do any git operations that don't touch the working directory. So, for my application, 'git diff v9.4.4..v9.4.5' works great. Of course you can also do git operations that do touch the index and the working directory but then you need to be careful that that repository is at the right commit for the release that you are sitting in.

I've also used this for multiple branches. In that case it is critical to use 'git symbolic-ref HEAD refs/heads/a-branch' to change the branch without touching the working directory. So when for my project version s3 came along, I did a 'git branch s3 v9.4.4', created my .git symbolic link, did 'git symbolic-ref HEAD refs/heads/s3' and followed it with 'add' and 'commit.'

GoZoner
  • 67,920
  • 20
  • 95
  • 145
3

This should work with no problem, but you may want to try running git fsck --full to verify the connectivity and validity of the objects in the database after doing that. By comparison, also see the Stack Overflow question "Can I copy a Git working copy onto another machine?". It's a slightly different scenario, but is relatively comparable.

Community
  • 1
  • 1
anarchivist
  • 1,387
  • 9
  • 20
0

Yes, that would work. You of course could also do the opposite - delete everything except the .git and paste in files from elsewhere.

Amber
  • 507,862
  • 82
  • 626
  • 550