I used reposurgeon to convert my svn into a git repository here: (How do I convert an svn repo to git using reposurgeon?).
The problem is, that the converted tags are shown in the log at the place when I created the tag and not at the place of the revision they belong to. In SVN they are shown at the right place in the log where they belong, no matter how long later I created them.
It seems like this has to do something with that reposurgeon adds a commit for .gitignore in each tag that looks like this:
# A simulation of Subversion default ignores, generated by reposurgeon.
*.o
*.lo
...
*.pyo
*.rej
*~
.#*
.*.swp
.DS_store
# The contents of the svn:ignoreproperty on the branch root.
*~
nbproject
*.project
How can I make reposurgeon not create such a commit for gitignore in all tags? And let it create simple tags that don't appear in the timeline as a commit?
user-generated .gitignore
This message means means reposurgeon has found a .gitignore file in the Subversion repository it is analyzing. This probably happened because somebody was using git-svn as a live gateway, and created ignores which may or may not be congruent with those in the generated .gitignore files that the Subversion ignore properties will be translated into. You'll need to make a policy decision about which set of ignores to use in the conversion, and possibly to delete either the generated .gitignore files or the user-created ones.
But no example how to make that decision. How can I manage this?
You'll need to make a policy decision about which set of ignores to use in the conversion, and possibly to delete either the generated .gitignore files or the user-created ones.
Do you have a .gitignore from before the conversion? If so compare it to the one from after. It seems like this policy decision is separate from your "sequence of commits" question, right? Basically, the policy question is just "get a final .gitignore you like". Do what it takes to get there.
In git, the .gitignore file is managed exactly like any other file. So you can say git log .gitignore and see what commits contribute to it. Say that the entire .gitignore file was commited in one block 10 commits ago and you want it parted out. If so, you can do a git rebase --interactive HEAD~11 and edit the commit in question. Do git add --partial .gitignore; git commit for each line you want broken out. Then git rebase --continue to conclude.
If you want the newly itemized commits to each be part of a larger code commit that they correspond to, then you would rebase -i again to shift the order around and squash them with their partner commit. If this sounds like unnecessary work, it probably is. If you can, I would recommend you focus on the integrity of the end state of the repo and less about a perfect expression of history.
Note: I don't understand your use of the term "tag" in this context, since both SVN and git have "tags", but you seem not to be referring to either. Perhaps "ignore line" or "entry" would be clearer.
To purge history in version control is problematic. Changing history on all branches is effectively creating a new repository, since there is no longer continuity to downstream followers for anything (everybody must rebase). But if you want to do it, for each branch, find all the .gitignores in the filesystem and see what commits touched them:
git log `find . -name .gitignore`
Then you can do the rebase --interactive steps described above to alter those commits. If the commit affects only the .gitignore, you can delete it. But obviously if the commit touches 100 files including the .gitignore, you have to separate out the good from the bad.
Alternatively, if you know the paths of all the .gitignore files (checkout each branch and run the find from above), then you can do something like github has documented with filter-branch:
git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch .gitignore path/to/other/.gitignore' \
--prune-empty --tag-name-filter cat -- --all
They also mention a BFG java tool, but filter-branch should do what you need.
After reading in your subversionrepository, just add:
expunge /gitignore/
That will remove all the .gitignore files that reposurgeon automatically added.
I've never used reposurgeon, but I've converted many svn repositories to git using the built-in git svn ... commands. I've followed the directons on http://trac.parrot.org/parrot/wiki/git-svn-tutorial and http://john.albin.net/git/convert-subversion-to-git.
@robrich
Author of reposurgeon here. Do not use git-svn for conversions! It's a disaster area. See this PSA:
来源：https://stackoverflow.com/questions/22822020/convert-an-svn-repository-to-git-with-reposurgeon-without-creating-gitignore-fi