2

I'm having a hard time figuring out a good title, so if you have an idea how to express my problem in a clearer way, please edit.

I am working on a big project which uses SVN. Since I am used to using git (committing often, working with many branches) and also don't want to change my workflow, I set up a git repository in the parent directory of my SVN working copy for local version control. All SVN related files have been included in the .gitignore. Using git-svn was not really an option for me because I didn't want to "pollute" the SVN repo with all my tiny commits.

Now recently I have begun work which is closely related to the work of another person (call him person B) on the same project. He however does not feel ready yet to push his work into the SVN repository, so initially he gave me his changed files manually and I included them into my project in branch topic. Since this procedure is quite laborious, we decided to use git for exchanging progress on the project.

Because I did not want to mess with the SVN of person B, my idea was the following:

  • I created a bare repo from my git repo and put it on a server which is accessible by person B
  • person B runs git init, copies my .gitignore file, runs git add . and makes his initial commit
  • person B renames his branch to topic, adds the bare repo I created as remote origin and fetches all the data

Since I had already included his work in my repo, person B's topic and origin/topic should now not differ at all. But they do.

Two problems that I have encountered (there are possibly more):

  • Some files have been added to person B's git repo even though they were on the .gitignore list (which is the exact same file that works fine for me)
  • When running git diff topic origin/topic it shows one file which definitely exists in both topic and origin/topic as deleted (path in origin/topic: /dev/null)

Does anybody have an idea what is going wrong here? Also suggestions for alternatives are welcome, but note that person B pushing his changes to the SVN repo and/or abandoning SVN altogether on the whole project are no options.

LLang
  • 121
  • 1
  • 1
    I'm confused when you say you don't want to pollute the SVN repo with small commits. Your commits don't hit SVN until you push, so you can clean up your history before pushing and everything will be fine. I'm doing something similar at work with Mercurial. – Ben Jan 09 '16 at 23:33
  • 1
    Another reason I didn't want to use git-svn was that I wanted to be 100% sure not to mess up anything. Also I would like to keep my commit history like it is, but just for myself. But thanks for your feedback! – LLang Feb 11 '16 at 20:42

1 Answers1

1

Note: the OP LLang concludes in the comments:

it turns out that simply copying the .git folder (from a repo my collegue cloned from the bare repo I put on the server) into the place where he kept his working copy did the trick.


Original answer:

Using git-svn was not really an option for me because I didn't want to "pollute" the SVN repo with all my tiny commits.

You still could have use git-svn, working in independent branches, and merge squashing your commits into the branch synchronized with svn.

Some files have been added to person B's git repo even though they were on the .gitignore list (which is the exact same file that works fine for me)

Check for differences (different OS, different git version, different shell, different paths).
Try and redo the same operation on your workstation to see if that still works as expected.

When running git diff topic origin/topic it shows one file which definitely exists in both topic and origin/topic as deleted (path in origin/topic: /dev/null)

/dev/null should means new file or deleted file.
Without knowning why the file is deleted, try at least to copy it and add it on B's side.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for your suggestions. After a few weeks of more important stuff I had the time to come back to this and it turns out that simply copying the .git folder (from a repo my collegue cloned from the bare repo I put on the server) into the place where he kept his working copy did the trick. I still don't know why the original idea did not work, though. – LLang Feb 11 '16 at 20:44
  • @LLang Great! I have included your comment in the answer for more visibility. – VonC Feb 11 '16 at 21:04