Re: help needed: Splitting a git repository after subversion migration

From: Thomas Jarosch <thomas.jarosch@intra2net.com>
Date: Dec 12, 2008, 14:22 UTC
Message-ID: <200812121522.38791.thomas.jarosch@intra2net.com>
In-Reply-To: <20081211081009.GA14639@atjola.homenet>

On Thursday, 11. December 2008 09:10:09 you wrote:

Show 17 quoted lines

> > Now I'll manually check the history of the tags/ and branches/ folder
> > for more funny tags and write down the revision. If I understood
> > the git-svn man page correctly, I should be able to specifiy
> > revision ranges it's going to import. I'll try to skip the broken tags.
>
> As long as the breakage only involves branches/tags that are completely
> useless, it's probably a lot easier to just delete them afterwards.
>
> And if you accidently added changes to a tag, after it was created, it's
> also easier to manually tag to right version in git, and just forgetting
> about the additional commit.
>
> And for a bunch of other cases, rebase -i/filter-branch are probably
> also better options ;-)
>
> Skipping revisions in a git-svn import sounds rather annoying and
> error-prone.

Sounds very reasonable. When I'm done filtering with filter-branch, the original commits are still stored in "refs/originals" and the reflogs. What's the best way to get rid of those to free up the space?

A nice way to find the corresponding commit for a file can be found here: http://stackoverflow.com/questions/223678/git-which-commit-has-this-blob

Thanks for your help so far!

Thomas

PS: Yes, I have a backup copy of the repository ;-)