Git: converting svn repo & stuff

[f0dder]

OK, so I've pretty much decided to move from subversion to Git for source control needs. Obviously I'd like my old version history to be ported over from the svn repos, and I've pretty much got that nailed (although there's some quirks to work out, because some of the first stuff I put under version control didn't follow a standard layout).

The tricky part has to do with fSekrit. Eventually, I want to open-source it, but I don't want the full version history to be available to everybody (for instance there's some ugly code in the early versions, swearing in comments, hardcoded passphrases for testing purposes, ...). So, the question goes: is it possible to do a Git setup with two repositories: one with full version history, the other with the "public" version, and the ability to push commits to both repositories? Or will I have to accept that the "historic" repository as a  read-only archive, only pushing changes to the "live" publicly available one?

[parkint]

There are many things about git that I am still learning (disclaimer: I am NOT an expert).
I believe the solution to your problem would be to set up a branch that is 'private'; only available to you.

Hopefully, someone with more experience will chime in here (and provide an example).

[f0dder]

Hm, *scratches beard*.

I know I can set the locations a specific branch push to... so, the idea would be importing the svn repo, and having that push to my private repo. Then, branch off the latest revision to a "public" branch, which would push both to my private repo and a public one; this should keep version history just fine, and keep everything in my private repository.

However, since the public branch would be based off the private one, would pushing the public branch cause all the prior revisions to end up in the public repo .git data?

[Deozaan]

I don't know how to do it, but I know it can be done in Mercurial. Not that that helps or anything. . . 

[ecaradec]

you might rebase -i to rewrite you public branch, usually people do this before pushing in public to clean up the mess. It's might not be super easy to merge back changes from the public branch if other people do changes though.

[f0dder]

Well, the idea is that development will only continue in the public/new branch, not the private/old one - but I'd still like file history from the public/new branch to track back to the private/old one... if possible, without the public/new repo containing the private data. That, or having the two branches entirely separate, but changes going to both the public and private branches.

[ecaradec]

After looking at it a little bit, it seems that git history must always be complete, there is no way to push half of a branch or have a partial repo (except shallow clones but they have limitation, that doesn't make them suitables as repository ) . But you may cheat by using grafts to stitch your history : http://bugsquash.blo...g-git-histories.html . If I remember correctly grafts only exists on your local clone and can't be pushed, it might be what you're looking for.