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.