Question

I have a repository that is currently using Subversion, but I’d like to use Git locally. So I’ve checked it out with git-svn:

git svn clone http://localserver/svn/repo

Now, inside repo, I have a few directories:

repo/
    trunk/
        A/
        B/
        C/
    tags/
    branches/

The repository is currently at revision 100. I’d like to checkout revision 90 inside repo/trunk/B and then make a tag for the whole repo, so that repo/trunk/A is rev 100, repo/trunk/B is rev 90, and repo/trunk/C is rev 100.

In svn I’d do

cd repo/trunk/B
svn update -r90 .

Is there an equivalent using git-svn, and can I then make a tag that captures the state of the entire repository at that moment?

I tried this:

cd repo/trunk/B
git svn find-rev r90      # yields 18376729f51b71212d94dcba239a2482cda9f3c8
git checkout 18376729f51b71212d94dcba239a2482cda9f3c8 .

And as far as I can tell, the files in repo/trunk/B have changed according to git status, but files in other subdirectories have not changed. Is this the right way to go about it, or is there a more “correct” way?

Answer 1

As you have mentioned above, you can use git checkout to do this manually for the files in trunk/B. The file contents will now show as modified, though, and if you ran git commit, you would be resubmitting the old files’ contents as new files.

This is generally not how git operates, and I’d venture to say that this is generally not what you really want to do with svn either. With git, you want the whole work tree to move together in lockstep, and as a result, support for partial checkouts or updating a subtree to a different version is nonexistent for the most part.

When this sort of scenario comes up, you should ask yourself whether A, B, and C are really different “projects”. When you tag, do you tag them together, or would you just tag A‘s files separately from B‘s? What about branching? I’ve found that git repos work best when you include all the files that are necessary a project but no more than that. Limiting repositories to the project level increases some bookkeeping but also helps with flexibility. This is why you’ll see many posts around StackOverflow discussing the use of git submodules and subtrees (two distinct concepts) for managing groups of repositories.