2

When using git svn, a sparse checkout of the central repository may be achieved by something along the lines of

git clone -s URL-to-root --include-paths 'dir1|dir2|dir3'

After using this setup for some time, I would like to add another directory dir4 to those tracked. This directory has existed in many commits that I have already checked out. Editing the variable svn-remote.svn.include-paths by running

git config --edit

does not have the desired effect on git fetch (only files changed in future commits will be checked out as they are changed; not immediately), and the following also does not check out dir4:

git svn fetch --include-paths dir4

I think the following would work but would be very ineffective due to refetching all revisions since the first revision at which dir4 appeared for the first time (let's call it REV):

git svn reset -r REV
git svn fetch --include-paths dir4
git svn rebase

What would be a better way of tracking dir4? What if I do not care about the history of dir4?

Is there a better way to do the initial sparse checkout with git-svn if I suspect I will want to change the list of tracked directories later? I have also tried starting by listing the directoreis that are not to be fetched in the original commit, but I do not know how to unignore them later:

git svn fetch --ignore-paths dir4

But how do I tell git to stop ignoring dir4 when I decide I want to check it out as well?

Ansa211
  • 462
  • 5
  • 9

1 Answers1

1

The reset section of git-svn man page https://git-scm.com/docs/git-svn/1.9.1#git-svn-emresetem states this:

... if you alter your --ignore-paths option, a fetch may fail with "not found in commit" (file not previously visible) or "checksum mismatch" (missed a modification). If the problem file cannot be ignored forever (with --ignore-paths) the only way to repair the repo is to use reset.

I think the reason is this: Git creates a separate git commit (identified by its checksum) for each svn commit in the svn history. By adding a directory to the history, the checksums necessarily have to change, so there is no way other than rebuilding the whole history.

The directory cannot be added even without recreating the history. A commit adding it would have to be created locally, and on an attempt to svn dcommit it, there is an error Item already exists in filesystem...

Ansa211
  • 462
  • 5
  • 9
  • I'm not convinced that `git-svn reset` actually helps unless you perhaps go back to the revision *before* the missing file was added. I'm trying to do the same thing and after many failures have reached this conclusion - but please prove me wrong if you can as it would help me a great deal ;-). – Paul D Smith Feb 25 '20 at 08:17
  • @PaulDSmith I think you are right, you would have to reset to a revision before the missing file was added. – Ansa211 Feb 27 '20 at 15:36