Home/ Questions/Q 7830553
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T11:16:59+00:00

I inherited a project stored in CVS. The previous developer has massive un-committed changes

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.’

    • 0